From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.dynamicdevices.co.uk (www.dynamicdevices.co.uk [89.200.136.37]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 6C31BE00474 for ; Tue, 22 Apr 2014 13:03:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by www.dynamicdevices.co.uk (Postfix) with ESMTP id 5F6AC27E00C; Tue, 22 Apr 2014 20:03:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at lennoab2.miniserver.com Received: from www.dynamicdevices.co.uk ([127.0.0.1]) by localhost (www.dynamicdevices.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7BVR1NXIkMP; Tue, 22 Apr 2014 20:03:13 +0000 (UTC) Received: from [127.0.0.1] (cpc32-live22-2-0-cust59.17-2.cable.virginm.net [82.36.253.60]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by www.dynamicdevices.co.uk (Postfix) with ESMTPSA id 5F8DD27E006; Tue, 22 Apr 2014 20:03:13 +0000 (UTC) Message-ID: <5356CAFB.6060802@dynamicdevices.co.uk> Date: Tue, 22 Apr 2014 21:03:07 +0100 From: Alex J Lennon User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mark Hatle References: <5353BA79.3060206@dynamicdevices.co.uk> <5355C79C.1020704@windriver.com> <5356112C.2050400@dynamicdevices.co.uk> <5356B18A.40201@windriver.com> In-Reply-To: <5356B18A.40201@windriver.com> X-Enigmail-Version: 1.6 Cc: yocto@yoctoproject.org Subject: Re: Question about rebuilding RPM package index for updated RPMs when bitbake completes 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, 22 Apr 2014 20:03:34 -0000 X-Groupsio-MsgNum: 19146 Content-Type: multipart/alternative; boundary="------------020509040807040205000208" --------------020509040807040205000208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/04/2014 19:14, Mark Hatle wrote: > On 4/22/14, 1:50 AM, Alex J Lennon wrote: >> >> On 22/04/2014 02:36, Mark Hatle wrote: >>> On 4/20/14, 7:15 AM, Alex J Lennon wrote: >>>> Hi, >>>> >>>> I'm trying to put in place a development workflow using the PR server, >>>> RPM package feeds and smart update/install on a target. >>>> >>>> I see that when I modify and rebuild my recipe, foo, the PR server >>>> increments its count within the RPM filename, but the RPM feed data >>>> doesn't seem to update. >>>> >>> >>> ... >>> >>>> So if I am understanding the above correctly, when I make a change >>>> to a >>>> recipe and build it, PR automatically >>>> updates, the old RPM is removed and the new RPM added to the feed >>>> directory. However the package index >>>> for the feed is not updated. >>>> >>>> So if at that point I try to make use of the feed on a target I am >>>> likely to find something is broken. >>> >>> The feed is normally indexed (createrepo) either when you manually >>> run the >>> package-index operation, or when you construct a filesystem. Until >>> you do >>> that, the feed directories are transient. >>> >> >> Is there a reason for this? Surely having a package index that is out >> of sync >> with the packages until a manual operation is performed isn't ideal? > > Yes, if you re-indexed the set of packages after each package, you > will add multiple minutes to the construction of each package, and > introduce locking into the system. (You won't be able to generate > multiple recipes in parallel due to this.) (I don't consider it a > package feed until all of the packages are built and the index is > constructed.) > I wasn't suggesting that the index is built mid-run . Not knowing the internals of the bitbake dependency chain, presumably the package index would/could be rebuilt at the end of the build process and so would not block parallelisation (which I agree would be a time-sink) >>>> If that is true would it make sense to leave the old RPM in the feed >>>> directory until package-index >>>> is re-ran, or to run package-index automatically at the end of a build >>>> when RPMs have changed? >>> >>> I -never- export the feed directories from the project directory. >>> Instead, I >>> copy the packages from the feed directory to where I share them, and >>> then run >>> the indexer against the external repository. This preserves the older >>> versions and also makes the new ones available. >>> >>> To run the indexer I have to configure and run it manually... >>> >>> PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH >>> >>> >>> /home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo >>> >>> --update -q >>> >>> So for qemux86_64, I end up running the above three times. all, >>> x86_64 and >>> qemux86_64. >>> >>> Then on the target I just do: >>> >>> smart update >>> smart upgrade -y >>> >> >> Thanks, that's useful >> >> However I still believe the core question stands, which is why the >> package index >> is out of sync, and why it's a good thing to have to run bitbake >> package-index > > The other option is to remove the repo indexes when packages are > written. Again, I don't consider these out of sync though, as the > files have different purposes and constraints. They are simply > constructed to enable the rootfs generation. Upgrades are external of > the build system. > Fair comment. I take the view that these feeds are available, could easily be relied upon not to be transient, and I'd like to use them locally to speed up my development workflow. I think other users would too. Much of the value of the build environment is the automation. If bitbake can do a task that means I don't have to remember to do it, and I don't have to explain to somebody else that they need to do it, then that seems like a win to me (even if that is an option I can turn on). >> manually to bring the package index back into sync with the packages? >> >> I too export the feed directories to a server for 3rd party >> consumption via >> compressed rsync over SSH. I don't want to expose more on the server >> than a >> simple SSH endpoint, and rsync seems a sensible way to minimise >> copying times, >> so either I need the package index to be correct prior to the rsync, >> I need to >> export, say, an NFS filesystem which I don't want to do, or I need some >> createrepo specifics on what I would prefer to be a dumb web-server. > > For an rsync, I would either index on the server using a cron-job.. so > when new packages appear they get added to the index, or have a local > mirror of the directory including the updated index... you just want > to make sure the index files are synced last somehow. > To me the server side customisation brings in in extra work that shouldn't be needed in all cases, (although will undoubtely be needed in some cases). I would much prefer not to have to worry about it. If the package feed could be relied upon to be in sync with the contents of the tmp/deploy/rpm/* tree at the end of a bitbake build then the problem simply goes away, potentially at the cost of a little lost time during the build. Understanding that other use-cases will be different from mine I have been wondering today, - Can I add something into local.conf that would add a dependency to cause the package-index task to run at the end of the bitbake build (preferably only if the contents of the package directories have changed? - Does the build environment have the concept of post-build triggers? i.e. Understanding that I could script something myself, is there a recommended method for defining a post-build trigger script for bitbake to run on certain conditions e.g to do the the package reindex and feed upload in this case? Thanks, Alex > --Mark > >> Best, >> >> Alex >> >>> --Mark >>> >>>> Thanks, >>>> >>>> Alex >>>> >>>> >>>> >>> >> >> -- >> >> Dynamic Devices Ltd >> >> Alex J Lennon / Director >> 1 Queensway, Liverpool L22 4RA >> >> mobile: +44 (0)7956 668178 >> >> Linkedin Skype >> >> >> This e-mail message may contain confidential or legally privileged >> information >> and is intended only for the use of the intended recipient(s). Any >> unauthorized >> disclosure, dissemination, distribution, copying or the taking of any >> action in >> reliance on the information herein is prohibited. E-mails are not >> secure and >> cannot be guaranteed to be error free as they can be intercepted, >> amended, or >> contain viruses. Anyone who communicates with us by e-mail is deemed >> to have >> accepted these risks. Company Name is not responsible for errors or >> omissions in >> this message and denies any responsibility for any damage arising >> from the use >> of e-mail. Any opinion and other statement contained in this message >> and any >> attachment are solely those of the author and do not necessarily >> represent those >> of the company. >> > > > -- Dynamic Devices Ltd Alex J Lennon / Director 1 Queensway, Liverpool L22 4RA mobile: +44 (0)7956 668178 Linkedin Skype This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. --------------020509040807040205000208 Content-Type: multipart/related; boundary="------------070102090204030301030209" --------------070102090204030301030209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/04/2014 19:14, Mark Hatle wrote:
On 4/22/14, 1:50 AM, Alex J Lennon wrote:

On 22/04/2014 02:36, Mark Hatle wrote:
On 4/20/14, 7:15 AM, Alex J Lennon wrote:
Hi,

I'm trying to put in place a development workflow using the PR server,
RPM package feeds and smart update/install on a target.

I see that when I modify and rebuild my recipe, foo, the PR server
increments its count within the RPM filename, but the RPM feed data
doesn't seem to update.


...

So if I am understanding the above correctly, when I make a change to a
recipe and build it, PR automatically
updates, the old RPM is removed and the new RPM added to the feed
directory. However the package index
for the feed is not updated.

So if at that point I try to make use of the feed on a target I am
likely to find something is broken.

The feed is normally indexed (createrepo) either when you manually run the
package-index operation, or when you construct a filesystem.  Until you do
that, the feed directories are transient.


Is there a reason for this? Surely having a package index that is out of sync
with the packages until a manual operation is performed isn't ideal?

Yes, if you re-indexed the set of packages after each package, you will add multiple minutes to the construction of each package, and introduce locking into the system.  (You won't be able to generate multiple recipes in parallel due to this.)  (I don't consider it a package feed until all of the packages are built and the index is constructed.)


I wasn't suggesting that the index is built mid-run . Not knowing the internals of the bitbake dependency chain, presumably the package index would/could be rebuilt at the end of the build process and so would not block parallelisation (which I agree would be a time-sink)

If that is true would it make sense to leave the old RPM in the feed
directory until package-index
is re-ran, or to run package-index automatically at the end of a build
when RPMs have changed?

I -never- export the feed directories from the project directory. Instead, I
copy the packages from the feed directory to where I share them, and then run
the indexer against the external repository.  This preserves the older
versions and also makes the new ones available.

To run the indexer I have to configure and run it manually...

PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH

/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo
--update -q <path to feed>

So for qemux86_64, I end up running the above three times.  all, x86_64 and
qemux86_64.

Then on the target I just do:

smart update
smart upgrade -y


Thanks, that's useful

However I still believe the core question stands, which is why the package index
is out of sync, and why it's a good thing to have to run bitbake package-index

The other option is to remove the repo indexes when packages are written. Again, I don't consider these out of sync though, as the files have different purposes and constraints.  They are simply constructed to enable the rootfs generation.  Upgrades are external of the build system.


Fair comment. I take the view that these feeds are available, could easily be relied upon not to be transient, and I'd like to use them locally to speed up my development workflow. I think other users would too.

Much of the value of the build environment is the automation. If bitbake can do a task that means I don't have to remember to do it, and I don't have to explain to somebody else that they need to do it, then that seems like a win to me (even if that is an option I can turn on).

manually to bring the package index back into sync with the packages?

I too export the feed directories to a server for 3rd party consumption via
compressed rsync over SSH. I don't want to expose more on the server than a
simple SSH endpoint, and rsync seems a sensible way to minimise copying times,
so either I need the package index to be correct prior to the rsync, I need to
export, say, an NFS filesystem which I don't want to do, or I need some
createrepo specifics on what I would prefer to be a dumb web-server.

For an rsync, I would either index on the server using a cron-job.. so when new packages appear they get added to the index, or have a local mirror of the directory including the updated index... you just want to make sure the index files are synced last somehow.


To me the server side customisation brings in in extra work that shouldn't be needed in all cases, (although will undoubtely be needed in some cases).

I would much prefer not to have to worry about it.

If the package feed could be relied upon to be in sync with the contents of the tmp/deploy/rpm/* tree at the end of a bitbake build then the problem simply goes away, potentially at the cost of a little lost time during the build.

Understanding that other use-cases will be different from mine I have been wondering today,

- Can I add something into local.conf that would add a dependency to cause the package-index task to run at the end of the bitbake build
  (preferably only if the contents of the package directories have changed?

- Does the build environment have the concept of post-build triggers? i.e. Understanding that I could script something myself, is there a recommended
  method for defining a post-build trigger script for bitbake to run on certain conditions e.g to do the the package reindex and feed upload in this case?

Thanks,

Alex


--Mark

Best,

Alex

--Mark

Thanks,

Alex





--

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype <skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged information
and is intended only for the use of the intended recipient(s). Any unauthorized
disclosure, dissemination, distribution, copying or the taking of any action in
reliance on the information herein is prohibited. E-mails are not secure and
cannot be guaranteed to be error free as they can be intercepted, amended, or
contain viruses. Anyone who communicates with us by e-mail is deemed to have
accepted these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from the use
of e-mail. Any opinion and other statement contained in this message and any
attachment are solely those of the author and do not necessarily represent those
of the company.





--

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Company Name is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.

--------------070102090204030301030209 Content-Type: image/png; name="ddlogo-4.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ddlogo-4.png" iVBORw0KGgoAAAANSUhEUgAAAGwAAAA9CAIAAADH1hvIAAAAK3RFWHRDcmVhdGlvbiBUaW1lAFNh dCA1IEF1ZyAyMDA2IDExOjQ5OjUwIC0wMDAwVeKl8wAAAAd0SU1FB9YIBQoyDghCEsEAAAAJcEhZ cwAACxEAAAsRAX9kX5EAAAAEZ0FNQQAAsY8L/GEFAAAO9UlEQVR42u1bCVSTV9pO8mUPCZCEJRBA IOyIIrsoqK0V6WAttWptj7b+dSynOgenY4ttbe3ixsyUaWfmzHRmOv7/eMbxt1qrtra4DZsisshO kB0hQEIWkpB8+ZJ8mTeEIlJEtEySzvgcjid+ufd+733u+z7v3UK0WCyER/hhIDnagP8EPCJxDvCI xDmA85IoGx7Oyc2NSUgovHTJ0bbcB85IosFg+PXHH0fGxpqNxtwdO3766qtr169v6+hwtF33hsWZ gOP4F2fOiKKjH8vMvFlXh1ssJrNZq9W+8/777gLBG2+/PaJWO9rGaeBEJFbfvLk8IyN0wYIvz50D NkdRQ3u/tKl7YEilNuN4Z3f3uuefF4pEf/3b30wmk6ONvQtOQaJkYGDrK694+vl99MknKIpiRtNt qbK+s7+hS2L7a709NDKqh5L/LC6OSUpKXrasvKLC0VbfgYM1UafTHcjPh+zBZDAaa2pAATWo8ZZE phrVE4nEiWKYydwrVXYNypOTU6rKyjZv2rT22Wdf2r4d2HewGo7BYSRCwB7//PPo+PjS8vKiCxd+ +9FHdBa7vV82qNRY8OkXUaMo1tEvk6pGt23dCoy7MJkLEhN/WVAAzusw/sZAtNh92QdvrKisfG3P Ho1anX/gQMbKleBogwr1yN3eNwNIJIKXG4fLZjY2N+fu3t0/MPDL/fufzMggkRzjE/Ymsae39619 +0Da3s7Le/nFF0kIMjwyCn8gzg/aFBUhCfhuLBoFEtHuN98MCwn51cGDkRER9uyODfYbOrVG8+4H H8Snpgq8vRsqK3O2bRs1mNr6hmUj2odgEICZ8e5BeY9Umbk6ExpcnJy8bNWq1/LyFEql/fgbg/08 MTktjcfjFeTnh4aEQAIeUKi1esMs4/c+fSAQuBympxu7XyLJ27u3pLT0zOefx8XG2qdfALLd3qQa GTm8f3+ISATc9coUOE64L4M0CpnHZs6yfS2K+QuFx44cWbx8eWdn538miTa09vaPaEfDAoRytU6P mWYuDCQiLtor2G9nLkYkkAKRRF8k5rqxKpmSrVKp6HS6PTtlbxKNJlN1a0fbbUlSVJi3OwcE0YzP pCcmgmHAIp6hAJ8YGEd+phWv+LN+ZySyHEiEhzw+356dsjeJNoAXXqysFXrykyJDzRaCUqN/CGFm EFzjyetQAvYXbOeQxZHbE44h0YY+6bBEJo8OCogKClBqUZ0Bm2VFhECJRFZ6kcK/Mn7UiF+Z/BXk SVhoI/adMDqSRABusdR3dLf3DSRGhfrwuDKV1mjGZ6xB9CfGRpFXlZmOHzW+aSJM5R2SFZFEcmGx 7NkLB5Nog85gKKpp8OK6JUeFIQhFrhmddt7lThDGU57txhsLDBu1BLmjrb4DpyDRhiGF6mzZjTB/ nwUhQVo9ptHf8TI6gR1LfhqsPYrl9VmaZmjEaDSiej1hLqafs4cTkUgYUzRxT3/3gDQuTOTn7Wk0 mUkEBORPSIo9b/y4Dv/2vmub8b2p/2YSbYD1zNWGFl5v39KYSCbRfcjSf9zwPkbQO9que8IZz1hs kI9oGjp7ZZbuQtPvZs8ghmFajcbOptqVRJPJJBL6RAb6k5A5fi/RQgwnpWVRf44ZjRDwLPtmZ/uR GB8Xl5Obe/bc2SXzw59JT4GZ9lztfXgSA3PoR35BPyWp1j+9fn1gQACHzbZbvwj2JPHoZ58VHD58 ID9/xerV7a3irNSEjOQ4d7bLD2mTSXDNpr61j1EikMb/9NWd2Rs3rsvOvlpU5ObmZrd+EexJIsyC n8zIqCgt3bhuXfamTVu2bSObsWdXpMLckEZ54PxGspAXkze8zyxbbsz5pODTuNRUCpVac+3azpwc Oo1mTwYJ9k8sJIS8cdPm8+fO40QkITX1w0OHggUeGx5Pi5gnnKUpIH/BxKQ8xldbKb8v+aomNjn5 i7Pn/vLnvx788BDfw8PO3fnOJHttymIms85ghAWybRsR3tvQ0HDg4Ie9Pd3v7d373Pr1Co32ap14 QC6f2GcM9hVEJdDe0S+ZaIRH8MumvZ2IrK2vb96zd29z6603Xs9bs+YpMtnqy1CPRaOx6BQ7zxPt RyJqNKl16JSNL7PZfPHihcOHD7q5uR7+4IOlqakdkqHrjS0aHTqFRJqFuZL6SgZlp0ZmeO/AgRMn T27e/OL27TkcDueu/hAsLAaNTbdrRNsvnOkUMp/DcmHQJq/JEATJyFh9/nxhZmbWhs2bn9uyhWjQ bXw8PSEihEpBxk20IPHI2veYJavxX3z2x2MQvwNDsnPnvtm9+40pDNLICI/NsjODBIccmZrNuFqP oRg2ZYUrlUk/+fg3Z8+c/p+tW1/ftYtMpQ3IlZ5C0pClI5SY8k3hhT3vvkumUN56c29KyuIpRwtk EsJmUukPnqB+rCTaYDCaNCj8c9fGl3XtLBYfOrS/RdzyTl7elhdeoFAp4tZbr+/ZU9vYuGvXa89k r6NSqZOrgPy50KlMGmVOzrx+ZCTaKNNjJrUenWICjpuLiouBShqZHJ+QcPLUqfUbntvx6k53d/cp 1Zl0KodBs3Ma+T4cSaINOG7RGjCd3mC5mwsURf//xPEbN27syv25SCSa/BXYTKWQXZl0MkJyMH9j cDyJNpisQomimOm+UQm8cZh0R8nftHAWEm0wWKdBBhM+/QmBdfpCh2kg1eHxO9UwpyKRMBaqowaj FsUmG2aVPxoVEgh5rrd/5gROR6INMCfXooZR1Lq8QRCiK4P+EOtru8FJSbTBaMaNZjODQnGy8J0K pybxxwJnlJgfHR6ROAdwXrV2EoDc3eobDPMT9A8rJXKFhUAM8fVq6x+iIeQgH08203r97P6e2NDe cfh/j/27be2RDDZ3dP07Wu4ekI5oRx+6Om6xyDXW6gKuG8FCDPX1NptxBpUSIvSqaeu2lbk/ibAs w0yzvWr00CitrTtTUjbnzQIFFU3iTsngD2+KBCtMIsF6Vcp624fEpNMmFlczhTN48kNvjTxo3ecy Vk6ZJ0xuAb7QowZgxIUxze1Ny9iN4+l7TiSuW75k8q8Kvl94huo2oAasQyIN9vGceKLSjtZ29PDd xs8Up5/inLxUVFxdA9NcDpOZGBVR19aeGBmBmUxZaam2Ap+eOhPi71fZ3Dw/OPhqXb1WjwZ4ee/Y mE2lUDQ63dGvC1s6e2hUamxYMIxaVHBgZOC8gmMnUuZHnb5SDO2sSVui1GiKq2ppdMpLWU/GhARf qawZVqrWP7FCh6LHvrlY09qKm3EXBvOtl7e4c9hXahoGhxXAqRk3p8ZEBgq8wAa9ASupa5YqlEAB i0Fftmi+ZFjRJ5OvShy/aFwlbjdgmA41+Hl5hAcIh1XqsoYWKA8+5eXunrUkEVq4XFWr0mphvHiu 7LSF0TBIPYOykromHMf9PfnpsdFgv0ylhld7uLJHRnUsOh0YU2pHOfBKCuWennitvrGouib3+Q3z BN5y1UjB30+wmPSwef75//f3J1ISaRQKPKxqEmevSP/Htxd4HNf3tr9sMGL7Pj0CFZfFxf7x5Jcu TEZ+bg6FTP5nZc3xwkv+Xl6gCZ19EqGnx/4d22+K2/70xdm1y5cW7P7Z+bLyfxRemi8K0hvQUb31 msPxwssyheqdbVu5HLZMOcIZO4aHLi0KCw7z9+2TykvrmiCm/L08im82uLqwHo9PB1+qbe/6+loV 8FLRdEuu1vA4bKPJ1NjevSolDp4YTaBjeGFFDbCZkbQIqmt01h+5fVNeJfLzyQyMBz+6Wt/ybXn1 M8sXQ/jHhgSFB/jWtXVBRRqV5Ok2vn/uyhq/QD7xZNzfv0/i5es3VqUkiYS+ZATx4nHXLLN63zwf gY+Hx/X6RvhcXF0bHRLk4W49202PW0gmIywGI9RfOCRXSGTD4q7eF1avYtBoUH1lckKgr2Ci5VUp ifAcxgO6sSJ+EYwHuDmKGczf7TioNJqK+qaXnsr05nHBqX09+ch3i2VbdPt58ROjQps6e7Q6fc/Q cIC3J9Ch0ev9vT3AreChSCho7OwmjF0O57BZAt74FmTPoBSCeunCKDq0S0a4HBepcmR4ROPrwVND Czp9WICvbESt0Gg93F2bu3qh/MLQIBqVMhstmsYTlVqtJ/fO9qc7e5z1xxLjCsuvL14wv6Smblt2 lu0hgoyfhNj0y4AZ3dkuzEmnHBzWneN5KvmOTbbyU3QTxYwWIsGFNdMvBlzodOg8ZgLm8aLapgkv 4DCsgRYjmne6qDw+PKSxqzcpInSiFggOm8mY/DIIc2ji4o3aiSdubBY4dfrC6I7+wWpxR7W4/aml ybPhcRoSIYprW9uSoiNt/70pvmX7kBAVAbF5pqiUQadGBAZM2xzol0qj7ZPKAgTehLHjFNmD/DSH zWSSiKSufsl8UfC9ynRJhiAIGDQqmYSsjI/xcHMlWLcjzaBl4FYwKgIP92v1LZCYAwR3UgEMbWXL LRTD6N+dLrBZDBiAn6TGuzAYBKvCGgbkSlBGoDvEzydYKDh+qQTcGUblYUhcuyzt4JGjR859PT84 6FbP7crmFq6r1VAIz/RFsV+XlT+fufJev6JzY7usWbbk9ydO/2RpCkTu5aoahUo9exJBrLNXpP3h 5JcZKUk+Hjx4e1baEvaYY8JcD0Ks9bZEoVZnJscDiQtDAwuv1ywKF8Fn0C8waZ63B0TGQlHQqaJr yxfFTN529OVzfXjc0yUVMcEBZISk1IwmRYaGBgjPX6uKDRNBwRpxB6gwDMmJy6Vx4SIIJpgPCD15 szEb2bdv35RHrmyXhWGhkMWGFEoeh7MmfakriwWaSLDOlUhVLeKXn84ij0UxhE/4vADG2LUN0GZv PteLywXJ47lyOiQDSrX6sYRFIQF+Qi/IbNagDgc1RBDi2GwLPtsaAY0S+fnCHIzryhHwecF+vqH+ /j0Dgz2SIW8+DyQVEpRCremXKjR6VMjnLYmJsskF+B2TTpeqRmDCAeKYEh1m0xYYCTAp1E8wITV8 Vw7EMjgXnUoeUqg0OtSL6wbJB2ohZGRQqdTpDZBh4sODIXgFfC4kNJ0Bg1TmzXWfDYkPsItjMpl/ d/ykwJO/4YnHZu9c/w2Y7dr54vVKEMTI4ECIL0fb7HR4tJ84B3i0FTYH+Bdk7tmQGqQ4UwAAAABJ RU5ErkJggg== --------------070102090204030301030209 Content-Type: image/png; name="linkedin.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="linkedin.png" iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA GXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAgRJREFUeNqUUs9r1EAU/jKZ7I+2 abBZVikKoYhCsbB/gXcFwV7Eu3jwInjyogdBj3oSPHm14KGhBwuC/gkKUqtVSglYarduKutu2c1m MuO82dqk1YX6YJL35r3vez/mWbWbCw3fd0PfnwjciQqOI51uH3HcjeK4M8+nToyHd640gnP1SViW dSwCpRS+7vwKniy9D7k3WQl2+xYWv7Sx2epgxmMmaKMtcbrmjiSZrjL4U+MBr5RsfGwlEJr1jGvh 8dXzJuD24hqa3cFIgt09C1zn4kJk6KViWBovlgmk2jdKUn0IyykoSYeBbzbbuPXyk9GXVluoudVD INtmqHtjOvNwVoTlmf5k+5mo+2fXZo3+4u5bbD24aPSVrQ7mpl20ewL3ltfxORaGhHCMylBCakNC SfXPcglM4lU5Hl4+i+bPPYMhLJNCoKQbNkQqJ2CFF1149x33X60fkIhMGgxhGZXBiUDPwS5kHXPy iT56HSH88COfhT6EMViZZXCMIeEUFsktOQe6c2TByCYMYfmAWPRlov92kaCcV2AfISCbvIRlqWYp QaGv+5KFxp1yXgHdF32kE4awVv3Gc3XpwizWegp6e1Fy7L9eYbC/J398tO0zXGJ5ZVW3kKTRt53t YO7kKXCnPGLvnEOWSBNsNLeRDkRkedefNsBYqN8twP+IVBGknP8twABFyPH3kUzF5AAAAABJRU5E rkJggg== --------------070102090204030301030209 Content-Type: image/png; name="skype.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="skype.png" iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA GXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAq1JREFUeNqMk0trE1EUx/935s4k k1czbVpfWEctRaFiKZiCUCjqooggxZ0KfgC/QcVF1/oRBLsRXQjxgSu7qAsFpYuWoliLTaSNUJvQ vJvceVzPndBSF0KHOTPD5fz+55z/vcNmXi2OZuKRHIWTiho4zFVruyg1OwWKaW7HzNz1kUEnk4pD 0xh2fQm6keDsvwJBIFGqNZ23K79yPBWNOJJH8K3q4VPVhfABjwQCSuSMQUiJXkNDNsVhHxDlxNgx y+GmYaDuMbwvd9Ck0gpOcg2Xeo3wW0Wx7ePhzxZuDZgYT/JQgJG4ruvgLrXzmxL24ITOMHM+jpj+ 7wg3jkVwb6kOUM5YQg/XFKu5gfroVhL0nsjwEF4stzA1v447Hzew0XIxHNcxngKebAnsMSo0EQSw qFggyUBaGDBl1yh6nemz8aXOcHm+gNmv23i52cAmVVmqtMmrAIrlqqpqNkqPbaKerlcw1hdDNtMN wMbrYh0vim209Cg6lL/ZEhhOmGHHmppDVeuQ221aWG4ZmFrIYy6/g4raErpunkjiebYfV9OgHImK 1ENm34OAYItcVQKTGQN3HRsPVko4+S6PoTc/sLDVCIXuD0ZD8ENdhoxiudpnNfVZk+FzQ+IKmTh5 JIGRnggerdWxQ1lpo+t6peOFB2SruUuMFZ4RrlSUgElx0fDx+HsNo7YVxrOstb+NapzZVeokiIJJ P2S6HVBPUs1Dj3MWx05TwzVyfaKXI22qygwVypwreqgYSWgywAUuQkaxXPg+dl0POtMgKMb7e3Cq WsdaTWBV7EKQwLLQ0NFMpDpVjBgebp8+GjLC82gEVxTWyjVnqC8F2+oe0+NWGmMHTqFH+91oC3A9 gUTERItgYuB6boEHnjtd+FPK5ctVR2r6oX5nRmMwTxSY707/FWAAwixkevHIXSQAAAAASUVORK5C YII= --------------070102090204030301030209-- --------------020509040807040205000208--