Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Hi Niels, > Can we not think of some better solution to this, where we can get the > reward sooner than 6 years without shoving all the risk onto me and > without shoving ton of work onto you? I hear you, ouch. :/ I had not appreciated all of the implications here, particularly in that that you would get all the flak from the fallout. Unfortunately, I can just imagine how this has played out in the past with other changes. I note that this bug has been marked as fixed in debhelper 13.2. To help others viewing this bug from reproducible context, here is the relevant changelog entry: * cmake.pm: Pass -DCMAKE_SKIP_RPATH=ON -DBUILD_RPATH_USE_ORIGIN=ON to cmake in compat 14. This should fix some reproducibility issues but may cause breakage if packages run binaries directly from the build directory. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Chris Lamb: > [...] > > In other words, unless you have no reason to suspect that lots and > lots of things will break, I would highly and strongly recommend that > you simply make the changes in CMake/debhelper and upload. :) > > [...] Hi, My concern here is that effectively, I as the debhelper maintainer will be accepting all the risk. In case of issues, it will drain my bandwidth (as well or instead of your bandwidth), because the RC bugs will be coming my way if it breaks. That sets me up to an "interesting" trade off of options. 1) I can accept the high risk and deploy the change now so we can reap the rewards now. 2) I can just punt it to compat 14 and say it will come eventually - but then the reward is 6-10 years away (for 80% coverage). 3) Obviously, I can also simply reject the change accepting none of the risk forcing you to test it first (or contest it at the tech- ctte's). Honestly, I do not think any of the choices sound very exciting. Can we not think of some better solution to this, where we can get the reward sooner than 6 years without shoving all the risk onto me and without shoving ton of work onto you? I doubt this will be the last time we will need some archive-wide change rolled out to all source packages to improve reproducibility. > > Thanks for working on this. :) > > [...] Same. :) ~Niels
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
On 30.06.2020 00:55, Chris Lamb wrote: > In other words, unless you have no reason to suspect that lots and > lots of things will break, I would highly and strongly recommend that > you simply make the changes in CMake/debhelper and upload. :) I'd say the biggest risk lies in breaking test suites for shared libraries, because they tend to be run from the build tree, which is why CMake adds RPATHs to targets in the first place. As precedent, I thought the way Debhelper introduced -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON in v13 was quite nice, and I wouldn't mind if I had to opt-in for CMAKE_SKIP_RPATH by bumping my compat level to (say) 14. Cheers Timo
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Timo Röhling wrote: > >> By default, CMake adds an RPATH entry to ELF binaries and deletes it > >> again at install time. However, due to the limitations of some > >> platforms, CMake will actually zero out the RPATH entry in the binary, > >> leaking the original path length and thus making the build not > >> reproducible (see the attached diffoscope output for an example). > >> > >> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and > >> since most package won't ever ship with an RPATH entry anyway, I propose > >> adding -DCMAKE_SKIP_RPATH=ON to the default build options. > > Thanks for the suggestion. > > > > Has this proposal been tested on an archive-wide rebuild test to see how > > much breaks with this option set? > > I don't know, but I don't think so. I'm not directly involved with the > Reproducible Builds Team, I just pinged them on IRC after I filed this > bug. Cc'ing them now. As Vagrant implies we have not done an archive-wide rebuild test on this specifically. (I was actually not aware of this specific issue until now.) However, let me give you my general thoughts on using our testing framework for staging changes. Although we do have the ability to make changes to our toolchain to test things we don't really like to do this unless absolutely necessary. Every deviation from Debian itself is a "bug" of sorts and only confuses users, developers and even the Reproducible Builds team themselves when things are (for example) reproducible in one environment or fail to build in a place that folks have zero control or visibility over. In addition, in the past when we have had temporary changes they have persisted far longer than anyone planned. This leads to frustration and highly-demotivating outcomes when maintainers no long feel a pressing need to accommodate a change because "well, all the packages are now reproducible". Well, yeah, I *guess* … Lastly, making just a small change is actually non-trivial to do and involves more technical and cognitive overhead than it sounds. "Just" is a dangerous word, as I am sure you all know. This could probably be fixed, but we have limited bandwidth and we aren't trying to be a staging ground anyway. I suppose this would be mitigated if we only needed to export that particular Debhelper environment variable from our 'master' build environment vs. uploading a patched package, but the above arguments still stand as a general rule. In other words, unless you have no reason to suspect that lots and lots of things will break, I would highly and strongly recommend that you simply make the changes in CMake/debhelper and upload. :) (Speaking only as myself, I don't represent the entire Reproducible Builds project, etc. etc. etc. And I am partly writing this so I can refer others to it later in other parallel contexts...) Thanks for working on this. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Vagrant Cascadian: > On 2020-06-29, Vagrant Cascadian wrote: >> On 2020-06-29, Vagrant Cascadian wrote: >>> On 2020-06-29, Timo Röhling wrote: >> By default, CMake adds an RPATH entry to ELF binaries and deletes it >> again at install time. However, due to the limitations of some >> platforms, CMake will actually zero out the RPATH entry in the binary, >> leaking the original path length and thus making the build not >> reproducible (see the attached diffoscope output for an example). >> >> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and >> since most package won't ever ship with an RPATH entry anyway, I propose >> adding -DCMAKE_SKIP_RPATH=ON to the default build options. > Thanks for the suggestion. >>> >>> Thanks for identifying the issue! >>> >>> > Has this proposal been tested on an archive-wide rebuild test to see how > much breaks with this option set? I don't know, but I don't think so. I'm not directly involved with the Reproducible Builds Team, I just pinged them on IRC after I filed this bug. Cc'ing them now. >>> >>> There is currently only one package tagged with: >>> >>> >>> https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html >> >> Also worth mentioning the upstream issue: >> >> https://gitlab.kitware.com/cmake/cmake/-/issues/18413 > > And BUILD_RPATH_USE_ORIGIN: > > > https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/prop_tgt/BUILD_RPATH_USE_ORIGIN.rst > > > live well, > vagrant > Ok, I will add a temporary undocumented variable for you to test this. It accepts any space separated list of "key-value pairs", which can be used to override -D flags passed to cmake. An example being: export DH_INTERNAL_RB_TEST_BUG962474="CMAKE_SKIP_RPATH=ON" But you can substitute it with other flags if you also want or need to experiment with other flags, such as: export DH_INTERNAL_RB_TEST_BUG962474="CMAKE_SKIP_RPATH=OFF \ BUILD_RPATH_USE_ORIGIN=ON" For the ease of debugging, debhelper will be verbal about this feature being used. It will be available with the next upload and be removed once your tests have concluded. ~Niels
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
On 2020-06-29, Vagrant Cascadian wrote: > On 2020-06-29, Vagrant Cascadian wrote: >> On 2020-06-29, Timo Röhling wrote: > By default, CMake adds an RPATH entry to ELF binaries and deletes it > again at install time. However, due to the limitations of some > platforms, CMake will actually zero out the RPATH entry in the binary, > leaking the original path length and thus making the build not > reproducible (see the attached diffoscope output for an example). > > CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and > since most package won't ever ship with an RPATH entry anyway, I propose > adding -DCMAKE_SKIP_RPATH=ON to the default build options. Thanks for the suggestion. >> >> Thanks for identifying the issue! >> >> Has this proposal been tested on an archive-wide rebuild test to see how much breaks with this option set? >>> I don't know, but I don't think so. I'm not directly involved with the >>> Reproducible Builds Team, I just pinged them on IRC after I filed this >>> bug. Cc'ing them now. >> >> There is currently only one package tagged with: >> >> >> https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html > > Also worth mentioning the upstream issue: > > https://gitlab.kitware.com/cmake/cmake/-/issues/18413 And BUILD_RPATH_USE_ORIGIN: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/prop_tgt/BUILD_RPATH_USE_ORIGIN.rst live well, vagrant signature.asc Description: PGP signature
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
On 2020-06-29, Vagrant Cascadian wrote: > On 2020-06-29, Timo Röhling wrote: By default, CMake adds an RPATH entry to ELF binaries and deletes it again at install time. However, due to the limitations of some platforms, CMake will actually zero out the RPATH entry in the binary, leaking the original path length and thus making the build not reproducible (see the attached diffoscope output for an example). CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and since most package won't ever ship with an RPATH entry anyway, I propose adding -DCMAKE_SKIP_RPATH=ON to the default build options. >>> Thanks for the suggestion. > > Thanks for identifying the issue! > > >>> Has this proposal been tested on an archive-wide rebuild test to see how >>> much breaks with this option set? >> I don't know, but I don't think so. I'm not directly involved with the >> Reproducible Builds Team, I just pinged them on IRC after I filed this >> bug. Cc'ing them now. > > There is currently only one package tagged with: > > > https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html Also worth mentioning the upstream issue: https://gitlab.kitware.com/cmake/cmake/-/issues/18413 live well, vagrant signature.asc Description: PGP signature
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
On 2020-06-29, Timo Röhling wrote: >>> By default, CMake adds an RPATH entry to ELF binaries and deletes it >>> again at install time. However, due to the limitations of some >>> platforms, CMake will actually zero out the RPATH entry in the binary, >>> leaking the original path length and thus making the build not >>> reproducible (see the attached diffoscope output for an example). >>> >>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and >>> since most package won't ever ship with an RPATH entry anyway, I propose >>> adding -DCMAKE_SKIP_RPATH=ON to the default build options. >> Thanks for the suggestion. Thanks for identifying the issue! >> Has this proposal been tested on an archive-wide rebuild test to see how >> much breaks with this option set? > I don't know, but I don't think so. I'm not directly involved with the > Reproducible Builds Team, I just pinged them on IRC after I filed this > bug. Cc'ing them now. There is currently only one package tagged with: https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html The tagging is not automated, so most likely there are more issues that people have not yet been identified... any good search terms for sources.debian.org that might produce a list to compare? The tests.reproducible-builds.org infrastructure has been building without any custom toolchains for quite a while now, but we did at one point have the ability to build with custom packages. It is best to be avoided, however, as then we have to constantly keep pace with whatever tools we're patching... It would be nice if this could be added to debhelper but disabled by default unless a flag was set in DEB_BUILD_OPTIONS (or something similar) so that we could enable it from the build environment in reproducible builds test infrastructure without affecting the official archive. live well, vagrant signature.asc Description: PGP signature
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Control: user reproducible-bui...@lists.alioth.debian.org Control: usertag -1 + buildpath toolchain >> By default, CMake adds an RPATH entry to ELF binaries and deletes it >> again at install time. However, due to the limitations of some >> platforms, CMake will actually zero out the RPATH entry in the binary, >> leaking the original path length and thus making the build not >> reproducible (see the attached diffoscope output for an example). >> >> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and >> since most package won't ever ship with an RPATH entry anyway, I propose >> adding -DCMAKE_SKIP_RPATH=ON to the default build options. > Thanks for the suggestion. > > Has this proposal been tested on an archive-wide rebuild test to see how > much breaks with this option set? I don't know, but I don't think so. I'm not directly involved with the Reproducible Builds Team, I just pinged them on IRC after I filed this bug. Cc'ing them now.
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Timo Röhling: > Package: debhelper > Version: 13 > Severity: wishlist > > By default, CMake adds an RPATH entry to ELF binaries and deletes it > again at install time. However, due to the limitations of some > platforms, CMake will actually zero out the RPATH entry in the binary, > leaking the original path length and thus making the build not > reproducible (see the attached diffoscope output for an example). > > CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and > since most package won't ever ship with an RPATH entry anyway, I propose > adding -DCMAKE_SKIP_RPATH=ON to the default build options. > > Cheers > Timo > Hi Timo, Thanks for the suggestion. Has this proposal been tested on an archive-wide rebuild test to see how much breaks with this option set? ~Niels
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
For some reason, the downloaded output from
tests.reproducible-builds.org was double-gzipped.
Here is the properly uncompressed text.
---
/srv/reproducible-results/rbuild-debian/tmp.xJYgDafRbo/b1/qhull_2019.1-5_amd64.changes
+++
/srv/reproducible-results/rbuild-debian/tmp.xJYgDafRbo/b2/qhull_2019.1-5_amd64.changes
├── Files
│ @@ -1,11 +1,11 @@
│
│ 041d4bd6e7ca3d9c2d084aba4c2a2a51 455784 libdevel optional
libqhull-dev_2019.1-5_amd64.deb
│ 5bb0c7f9a4aaeff49d15abe4cf5d5ee7 276048 doc optional
libqhull-doc_2019.1-5_all.deb
│ f5cc0b783287e8987edb2b84554b60e3 312616 debug optional
libqhull-r7deb1-dbgsym_2019.1-5_amd64.deb
│ 75fdb7fb92f855987e4d907572854628 243096 libs optional
libqhull-r7deb1_2019.1-5_amd64.deb
│ 79341e85a770de9f9ca750a20424f220 293268 debug optional
libqhull7deb1-dbgsym_2019.1-5_amd64.deb
│ 5a3b8870d1af8d7a5c7bfc211fb60921 241048 libs optional
libqhull7deb1_2019.1-5_amd64.deb
│ - 55095384a735b603c0999294438c0411 520484 debug optional
libqhullcpp7deb1-dbgsym_2019.1-5_amd64.deb
│ - 2530d91667aee70b67c485b5f94ab7ac 104240 libs optional
libqhullcpp7deb1_2019.1-5_amd64.deb
│ + 25d2ed322f5b5daa873ec63849901039 520488 debug optional
libqhullcpp7deb1-dbgsym_2019.1-5_amd64.deb
│ + 075608429f542b46d7ec16e34007929c 104448 libs optional
libqhullcpp7deb1_2019.1-5_amd64.deb
│ 0def6de5d02be4b63c76473a92e626d4 1479480 debug optional
qhull-bin-dbgsym_2019.1-5_amd64.deb
│ fbf4f5abab361de0e9a0e26ddef7434c 475436 math optional
qhull-bin_2019.1-5_amd64.deb
├── libqhullcpp7deb1_2019.1-5_amd64.deb
│ ├── file list
│ │ @@ -1,3 +1,3 @@
│ │ -rw-r--r-- 0004 2020-04-29 08:15:52.00
debian-binary
│ │ -rw-r--r-- 000 2988 2020-04-29 08:15:52.00
control.tar.xz
│ │ --rw-r--r-- 000 101060 2020-04-29 08:15:52.00
data.tar.xz
│ │ +-rw-r--r-- 000 101268 2020-04-29 08:15:52.00
data.tar.xz
│ ├── control.tar.xz
│ │ ├── control.tar
│ │ │ ├── ./md5sums
│ │ │ │ ├── ./md5sums
│ │ │ │ │┄ Files differ
│ ├── data.tar.xz
│ │ ├── data.tar
│ │ │ ├── ./usr/lib/x86_64-linux-gnu/libqhullcpp.so.7.3.2
│ │ │ │ ├── readelf --wide --program-header {}
│ │ │ │ │ @@ -1,15 +1,15 @@
│ │ │ │ │
│ │ │ │ │ Elf file type is DYN (Shared object file)
│ │ │ │ │ Entry point 0x9ba0
│ │ │ │ │ There are 9 program headers, starting at offset 64
│ │ │ │ │
│ │ │ │ │ Program Headers:
│ │ │ │ │Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
│ │ │ │ │ - LOAD 0x00 0x 0x
0x008be0 0x008be0 R 0x1000
│ │ │ │ │ + LOAD 0x00 0x 0x
0x008be8 0x008be8 R 0x1000
│ │ │ │ │LOAD 0x009000 0x9000 0x9000
0x00e151 0x00e151 R E 0x1000
│ │ │ │ │LOAD 0x018000 0x00018000 0x00018000
0x005f85 0x005f85 R 0x1000
│ │ │ │ │LOAD 0x01e610 0x0001f610 0x0001f610
0x000a08 0x000cd0 RW 0x1000
│ │ │ │ │DYNAMIC0x01e738 0x0001f738 0x0001f738
0x000240 0x000240 RW 0x8
│ │ │ │ │NOTE 0x000238 0x0238 0x0238
0x24 0x24 R 0x4
│ │ │ │ │GNU_EH_FRAME 0x019a4c 0x00019a4c 0x00019a4c
0x0009bc 0x0009bc R 0x4
│ │ │ │ │GNU_STACK 0x00 0x 0x
0x00 0x00 RW 0x10
│ │ │ │ ├── readelf --wide --sections {}
│ │ │ │ │ @@ -2,19 +2,19 @@
│ │ │ │ │
│ │ │ │ │ Section Headers:
│ │ │ │ │[Nr] Name TypeAddress Off
Size ES Flg Lk Inf Al
│ │ │ │ │[ 0] NULL 00
00 00 0 0 0
│ │ │ │ │[ 1] .note.gnu.build-id NOTE0238 000238
24 00 A 0 0 4
│ │ │ │ │[ 2] .gnu.hash GNU_HASH0260 000260
0009ac 00 A 3 0 8
│ │ │ │ │[ 3] .dynsym DYNSYM 0c10 000c10
002520 18 A 4 1 8
│ │ │ │ │ - [ 4] .dynstr STRTAB 3130 003130
003f97 00 A 0 0 1
│ │ │ │ │ - [ 5] .gnu.version VERSYM 70c8 0070c8
000318 02 A 3 0 2
│ │ │ │ │ - [ 6] .gnu.version_rVERNEED 73e0 0073e0
000120 00 A 4 4 8
│ │ │ │ │ - [ 7] .rela.dyn RELA7500 007500
0005d0 18 A 3 0 8
│ │ │ │ │ - [ 8] .rela.plt RELA7ad0 007ad0
001110 18 AI 3 22 8
│ │ │ │ │ + [ 4] .dynstr STRTAB 3130 003130
003f99 00 A 0 0 1
│ │ │ │ │ + [ 5] .gnu.version VERSYM 70ca 0070ca
000318 02 A 3 0 2
│ │ │ │ │ + [ 6] .gnu.version_rVERNEED 73e8 0073e8
000120 00 A 4 4 8
│ │ │ │ │ + [ 7] .rela.dyn RELA7508 007508
0005d0 18 A 3 0 8
│ │ │ │ │ + [ 8] .rela.plt
Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds
Package: debhelper
Version: 13
Severity: wishlist
By default, CMake adds an RPATH entry to ELF binaries and deletes it
again at install time. However, due to the limitations of some
platforms, CMake will actually zero out the RPATH entry in the binary,
leaking the original path length and thus making the build not
reproducible (see the attached diffoscope output for an example).
CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
since most package won't ever ship with an RPATH entry anyway, I propose
adding -DCMAKE_SKIP_RPATH=ON to the default build options.
Cheers
Timo
í\ÝrÛ8¾î~
ÜÅnE2$¨Úb+ºm9m)Îlui@´¹#nNìÞÚª©}¾Ü§ë'Ùúå¿ì¤{«¢ØRßwÎÁÁÁH¢Ûí¢8úxÛ(ôîÜÀn$â»yDÎ]0÷ºp¾#¶{¸kÌøÂ3iϽáËkÛét&Õпÿö¿¿ÿößð^sõÿ¡/P?ÇuÔß/T-Jÿ"b:),ëíOc;ºn`D
ÃbÍÇ Å
·I.ù\Ö(Y@Ôûòô¾á8kù6§ ߧ¶
îêúga!beÈ Ý"èÐÝÏ·}Ãu5Çb:a`6üñ â0:¦¤cbbÁ7î® #
Îà®ç\Çrù-Ã÷ Ëwlâ3Ã4Ô³5Ë°3¨I"T×lSâÆ¥,ð¶N±`·,Ͷo»Ü24N4J¨OiÑLëc@¹Ï<®åø.ÁØKÙX¶A±tah¶¡ÏXºpº«Ù¶MlJuæsad2à@%¸··Mè"bègcÓ´8¸æKá¾
îjqai3DM~ð="< @=Î¥ ×Ål[Ãn§z°GêÑAà;û%5=K¸Ø:Õ4 ì¦ô ¥Q§thOø¦'
O#ÐÍ Sw-Z:·0éQ©eS¦í+ú«,kÝÉw|êC'ænbOhÂæ h
¶¨N]D-êðä¦ ¿x·*ºù¾'Yý*âé2àé«x§DïFºQWþHC¡ì?
hDëj´Kl¤±>6úéiêÒÈ,5áÑCKlbU`»á2Ây/áQïþ×5x·8/5µJÁyÂ÷;Íej
¼j
/Ø:»}EïdáñÝ"Þ;ßôýþÛÿ¤Ã!òßÑEfÉ-î.NÀiOî93iw ,ïî»×Ë»-OîÅaÏêé=R¡B$¸'æ>´õ§ÀP@np ñE÷FÐþWn«ÑÝP£»±ííÛ¿¨¸v|ªû$·1:û0FG
Î7QçK¾M÷nÃ` íÞv¸V|ÝôFD(²Q¦Jµ£ËkÄú~,dÒ6J¼Íߤýâ«@
©ãæsr!ô>çE[çÞÞ<Ä{UÒ&Á¯]
*Ñ«ù5Ìëe!!t§óËÁÙvõÕÁæSVÅ ±up¥@0,dì<#Û Ô0¢BF;_U%0$ë+4lÍY¾²ÊLnspXx Þ¯ªâZjUÍõ
ÿVÇÝpp1:Ýa´t¶_U%S¡õAÊÈÊèÆÓá¾Û}ì*B7©IiÝëñ»ÙðÍìÕÕàbiÓwOÊ*ÛÙ:h@7N8¸Sì ¬¯M,!BWEqò Û¨£þ¶â¼6 þû8úùb;
æã"OÄñN¤D=yÝp¢"ßù?ÑhéC ,eCÚÏ(ÿ¿;?ßþÞà{Å&_
ÿzË0={{é :ðö]å½w](<5 -§#@'nx|³F®öf0ySÌf*²ÂËMOÙX9lÞÃÒò-]
JL>\èæbEæ.³Ê®+ÙhÆléÕtð²MǺ¤Y¾mí[³%?ïJ7V÷ëRÝ,Í
À
Ù±$)g3wÙfQÆ6 ÏÙt9¯
H
µµnTMª,i[$æ\s~5< ù$Lþ[Zh0[·[¥(6¶b»'Íظ§ØÒc²
F2¶ÎÓxÝÌK:zG뢹tõÖEs/é ê% æ^Ò9ÔKZͽDE.Øeì
o¯._¿ M'Elib¸*/%De CÎZ
ØHʦ
ͱ@· 6l³áw &
Ù [±¥èÛÑÜX8¸oaI¡uáíY²J79âøÐpMÙ°
)àg
¢oÑn2D¡k7dKù¬Ð°J
wbNÊÙd,73 fbvMóªØÒÄ3+²ì³>S(Í¡÷
n\=£·å¾e&ؽÀ\%YÆ#˳¶v¯F¹øÂHKMLæQ=vÚ!³æÈ»sñÍË°2MÍÃÂ
çÏbôÏïÄÖÿUÛ¬XzÅ´¹yÚ~&
³ßÙOjMg&ãtô~Ê>©khØãh°×¿|9;LKæP³Ùõ²µ´6ÉM(ÅÚЦÑr4½Eâ:M/NçáRL¹3Ù7
íÙÿ>I¨+¢èÅëóÑËÓ~é=ÚÙßèm À<}?$ÖlæÞßCnd8<\0},¯;äNÝ ÍIW=\¨S?Þª_ÏC
Ì[ÐçDÞVEY[Æ6:GÓÙàêjðáxk
^å¬MQmÉßW8Ò-è,ÇM8:zP
ò8åq·Q6ò°ÆÒ0
úÂ7ÐÑjÅõxçþEiÊ_átÍêx'¾j÷rª) .
@ÜFêæ1¸dcu#Ë®4L§
Ã-\snÃñtж@::z{>}}9Ý7ôl5E!
Òñ]í¨n²¶ÎLWP»ÉT¿a£a }ñ6fM[ @$ç^cesôM^) kê7U4n!ì{ Oµt;
Úw¾Ö¾DóÁëÉf/Gã³ÙøòoÍï;Ì ï ½óë¸Êºy
'[M>Þ3´.ê¼kª¿¿»ØàЦhêû!r~YZSMª@xSM2g9½|·ã.Doêm
¼;÷þVɼY³¶GåÚ my÷,!|Oʤ~x·ôP°ìÜ÷,o\~ZhéâL.»Æòîî7g"v£@=²Wv
FÜüêÇÊ~3Îä üòÝèül6:CGwËà¢(ÑT80V³ããoT ÌêûH÷\Ïúkê¦O©¯9Ôµ N ÃÐ
ÛØ%áe·6>d"ÉÁÇã
ÆLÊ\fù¾"3×÷_ÏòÚøIvk©ÈÙ^õÃ]z¸Kké0ï³;e±Æ[³×;[Ï6óUÝ6«ç«]õh@¯ã¨Û°Ù46=ÖËB¢£ìÆuYòRÉs¼)fý÷ÕÂüÑw2··êÔ>lÍS\SÎA9ôï÷H:X<õKQè³WSÎãö
é.³}\xÕÌHôrm°j½« å67×d lÖË5Á´ië7j«r ÖobñBæ&/û¿ÍÔÚqZÎ ¶,Þw=
õ5å îçç`Úà _ãs·GuÔ_
áÄüY´õéA1_>
³UMi¨UÌNìc²¦ëþÊ}ù|j·/ß)¸vÝY, ÃÊÓ%àR{-Qr)µ^BÕÖYþ2\
´EbT2yR³,ú¶,Y&«Â¢eâ¸ÛâÐ*£@ ZjJÍÌ(\e·Zn¸¸U1v»7â¾ëÝ-nÿ²z\©*ÛÒ°®î½§ey¼M×{
Ã×u"tàÖ1Ì#¨n0Q(¡6ÆH.÷VÃW ¬|C(XùE(Nñä«mp``´{!±Wklu©MI&¤DSÒ
PÁi´3Ü÷^×Á2H$¤DDR' {
Jm´=Îê¨ÖÖP
*aWFÞ{PÖ¨Ù§k
ùÞÞ§ÖyBØîÖÍÞ®BëT¡m=dC+ÄkÛé`ä©wÍæÉKú|E'N<EÈÂúÇ¡àÿèÁg}4¢0áE=¾¨îWÃd°DÉ@êëS3KÎ̬³7â IéQèïÐMõ«ÝB5LuëÔ¤yt¨*øE¦©S&ÚQ×ÁÂ,S×LßÕå(|ÝPÿ4y`¤½y ,ïbèÒ"Ó0eÖÆÓù}O¡¾oȱ9qaú U|ê;bWÆè
R85¬ap¢ýu:XiO°L· Q Y,ÙLTÖ
U
1
´¿P ö̾ "Y&-±gº*QcÏÎ=ázÏâ¦WmÏ_¯lÖ¼@úg{s³Û
Û0ÌÏôæ¦mK7?ÇJlrØbSú¾]ómáWÏêÈ?¡]ÀÌGÎ~ gÊ'ÐÄ
ÄÒ[§bôo¿Äé¹îbsî
ôÚ¸ÇçAÜôÒëzatý×<ÙRN> ¯+_ éË÷åó
ù°BÜÏõ%tô´êGùÏêÕ~ú2÷·ïFa$ýõ{ØÖ¸'Aw¹7}C2^$ÝzU8cZ/*úa9ÐU+©ÝTðàEÞÎÈë±ûâ" Í
#¯ð¢,àA¸+K!º«×ÙOÖ ü'ºwÒ̽b×P&-7ôfÞªócBóÅpäEüQ1*
· Ì?ÒóëpVÅz'_H¶Ç%ÿÅ Soûh7NS_X ½H½· 0ÄÓêm%*exTé|aAdÊËð
mvXtü2 ˽Nþ J/t
hçVý|FÚùêþµ>5xÍçê «AMîøõÙüiÄÁ"óR´ø6HDe×Åè(vÃRPü ÍÃO";~,
fõÅã¯Û|ݤ;Äp¿ìö$ÛnO¢µÛDÛÙ§äíI
kw,yÜö$Ör{5õ¡Û2ÖìXòÿg{õbDíIÖÝäëö$íIÆÛ/8lOb¸O´=I%[¶=IÊöÛT±e;NdlO±=IÛj_ÌO°=I%[¶/IÆöÛT²eûdlO°=I%[º/IƶÞx"c;d{V^òèíIj¼ â%C½ â%C½ â%C½ â%åÛT±eûà§Û¤l³=Áö$lé¾$Ý ½=I5ßb{íI*ØVû¬u{üö$UllÇKb{*¶l_nÝduo§:d*d¥É`úF2JÔ Ïz
[
