[gentoo-dev] Re: About trying to prevent downgrades of packages that cause system breakage
Mike Frysinger posted on Sat, 30 Jun 2012 11:16:51 -0400 as excerpted: On Saturday 30 June 2012 07:22:39 Zac Medico wrote: On 06/30/2012 04:07 AM, Pacho Ramos wrote: I would like to discuss a bit more issues like: https://bugs.gentoo.org/show_bug.cgi?id=423087 Even if there are a lot of packages that can cause this breakage when downgraded, I think it should be prevented and package managers shouldn't try to downgrade this kind of packages as they will later cause a total breakage. People is not supposed to know that downgrading some package system will, for example, have an unusable gcc. It seems like a die in pkg_pretend would serve pretty well. doing it on a per-ebuild basis doesn't make much sense. a simple version compare (like we do in glibc as an exception to this rule because of its much wider implication) is incorrect: the new version might not introduce any new symbols compared to the old one, and even if it has, other packages might not have been linked against the new symbols. glibc was the example that popped up in my mind as well. Two comments: * Please make sure there's an override in case the user needs it, like glibc has. * Glibc's override is unfortunately broken in one specific case: binpkgs. The binpkg must have been built with the override (I_KNOW_WHAT_IM_DOING=1 or whatever) set, or it won't work. I found this out the hard way, when I upgraded a glibc and immediately found it broken for something or other. I hadn't rebuilt anything else yet (I try to do glibc upgrades by themselves, /because/ of their critical nature), so everything was still built against the old glibc and there would have been no breakage. Since I run FEATURES=buildpkg by default, I thought no problem, I'll just emerge the old binpkg. WRONG! Because it wasn't built with the override variable set, it wouldn't let me downgrade using the binpkg! But whatever breakage I had wasn't letting me rebuild, either! Which is exactly why I have multiple bootable rootfs (with everything portage installs on it) setup, so I can boot into a bakup root if my normal working one gets hosed, somehow. So I just booted into it, mounted my normal working rootfs, set ROOT= to point to it, and went from there. It would be MUCH easier if a glibc binpkg downgrade could look only at the existing portage environment for that variable, not check the one in the binpkg! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: About trying to prevent downgrades of packages that cause system breakage
On 07/01/2012 12:20 AM, Duncan wrote: * Glibc's override is unfortunately broken in one specific case: binpkgs. The binpkg must have been built with the override (I_KNOW_WHAT_IM_DOING=1 or whatever) set, or it won't work. You can always override environment variables (even for binary/installed packages) by setting them in /etc/portage/bashrc (or in a per-package bashrc in /etc/portage/env/$CATEGORY/$PN,$PF...). -- Thanks, Zac
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
Luca Barbato schrieb: On 06/29/2012 04:30 PM, Thomas Sachau wrote: It is interesting, still you need a way to define HOST dependencies (stuff you need that has to be built on the host since you run it, e.g. xcb python code generator), something to play properly with ld and cross-vs-host paths for compilers (that part is _really_ annoying for qemu-chroots) lu I guess, you are mixing cross-compile support in multilib profiles and cross-compile support with cross-toolchains, multilib-portage is for the first one, while crossdev is for the second one. My suggestion does not support e.g. compiling for ppc with an amd64 profile, on amd64 it only can support x86 and x32. Since all of these binaries can run with an amd64 kernel and you build for at least one target, you always have a binary around, no need for an extra HOST dependency. I dont know, what exactly you mean with play properly with ld and cross-vs-host paths, so cannot respond to those. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] New Manifest Hashes
As of Wednesday, July 4, 2012 at approximately 10:00 UTC, the manifest hashes used on the gentoo-x86 tree will change to SHA256 SHA512 WHIRLPOOL. To facilitate this change, developers MUST be using at least portage-2.1.10.49 (or portage-2.2_alpha89), or, if your dev-lang/python is built with USE=-ssl, portage-2.1.10.51 (or portage-2.2_alpha95) or later is required. For users, if they are on a older portage, it will gracefully downgrade. For developers, however, not using a supported version will cause tree inconsistencies. Developers will also need to make sure they cvs up metadata/layout.conf (or cvs up the entire tree) after this change occurs before making any commits. Thanks
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
Matt Turner schrieb: On Sun, Jul 1, 2012 at 7:29 AM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau to...@gentoo.org wrote: I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. If a package has dependencies, then those dependencies are required to have at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? All packages do get the ABI flags (with the needed EAPI or via enabled portage feature, which is currently in the multilib branch). If a package does not install anything ABI-specific (no headers, no libs and no binaries), then there is no overhead, since it will just get compiled/installed for one ABI, even if multiple ABI flags are enabled. I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. I dont follow. Did you think about only having additional ABI flags for certain cases? For mips, we'd like to have gcc built as an n64 binary, which would require its run-time dependencies (mpfr, mpc, gmp, etc.) to be available as n64 as well, but the rest of the system to be n32 binaries. Does this fit with your understanding (and proposed solution) of the problem? I guess, you require additional n64 libs for gcc dependencies like mpfr, mpc and others, while your default ABI will be n32. This should work fine with my proposal, you just have the (already default enabled) n32 ABI flag enabled, which results in everything being built just for n32. For the packages, where you require additional n64 libs, you just enable the n64 ABI flag in addition. And if you need n64 binaries too, you enable the abiwrapper USE flag for them. One follow-on question. Consider having a package dev-libs/libpkg already installed for ABI=n32 -n64 and wanting to emerge another package that depends on it with ABI=-n32 n64. Will dev-libs/libpkg have to be rebuilt twice (once for the existing n32 ABI and again for the newly needed n64), or can we optimize this case by recognizing that building for multiple ABIs means entirely separate builds? Those ABI flags behave the same as other USE flags: When you change them, you have to recompile the package including all the content, that has been compiled previously. If you want the compile for each ABI seperate, then you would have to handle them more like SLOTS, but with a new syntax, with a collision handler for the common content and how to handle that in the user UI. I fear, that this would be way more complicated to implement in a sane way, so i dont plan to go that route. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 04:29 AM, Thomas Sachau wrote: Matt Turner schrieb: On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau to...@gentoo.org wrote: I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. If a package has dependencies, then those dependencies are required to have at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? All packages do get the ABI flags (with the needed EAPI or via enabled portage feature, which is currently in the multilib branch). If a package does not install anything ABI-specific (no headers, no libs and no binaries), then there is no overhead, since it will just get compiled/installed for one ABI, even if multiple ABI flags are enabled. For a package like this that does not install anything ABI-specific, does the package manager still execute phases for each enabled ABI, or is there some way for the ebuild to indicate whether or not its phases need to be executed for each enabled ABI? -- Thanks, Zac
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
Zac Medico schrieb: On 07/01/2012 04:29 AM, Thomas Sachau wrote: Matt Turner schrieb: On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau to...@gentoo.org wrote: I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. If a package has dependencies, then those dependencies are required to have at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? All packages do get the ABI flags (with the needed EAPI or via enabled portage feature, which is currently in the multilib branch). If a package does not install anything ABI-specific (no headers, no libs and no binaries), then there is no overhead, since it will just get compiled/installed for one ABI, even if multiple ABI flags are enabled. For a package like this that does not install anything ABI-specific, does the package manager still execute phases for each enabled ABI, or is there some way for the ebuild to indicate whether or not its phases need to be executed for each enabled ABI? This is dynamicly checked at runtime, no need to modify the ebuilds and also no needless compilation, when there is no ABI-specific content. A more detailed answer at package manager level: After the src_install phase for the first requested ABI has been finished, the content of $DESTDIR is checked. If there is no ABI specific content, the other enabled ABIs are skipped and the following steps are done as usual. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. I dont follow. Did you think about only having additional ABI flags for certain cases? Right. It seems to me that not having the ABI flags for packages like x11-proto/* would make more sense, but may be more work to implement. Those ABI flags behave the same as other USE flags: When you change them, you have to recompile the package including all the content, that has been compiled previously. If you want the compile for each ABI seperate, then you would have to handle them more like SLOTS, but with a new syntax, with a collision handler for the common content and how to handle that in the user UI. I fear, that this would be way more complicated to implement in a sane way, so i dont plan to go that route. Ouch. I already think a mechanism for telling the package manager you don't need to rebuild this entire package to turn on /this/ USE flag is needed. For ABIs, the situation seems much more clear-cut. In fact, it seems rather important.
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 02:39 PM, Matt Turner wrote: On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. I dont follow. Did you think about only having additional ABI flags for certain cases? Right. It seems to me that not having the ABI flags for packages like x11-proto/* would make more sense, but may be more work to implement. It seems like this could easily be controlled by setting a PROPERTIES or RESTRICT value in the ebuild. Also, it might be useful to give the ebuild similar control over the abiwrapper flag via PROPERTIES or RESTRICT. -- Thanks, Zac
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 02:34 PM, Thomas Sachau wrote: Zac Medico schrieb: On 07/01/2012 04:29 AM, Thomas Sachau wrote: Matt Turner schrieb: On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau to...@gentoo.org wrote: I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. If a package has dependencies, then those dependencies are required to have at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? All packages do get the ABI flags (with the needed EAPI or via enabled portage feature, which is currently in the multilib branch). If a package does not install anything ABI-specific (no headers, no libs and no binaries), then there is no overhead, since it will just get compiled/installed for one ABI, even if multiple ABI flags are enabled. For a package like this that does not install anything ABI-specific, does the package manager still execute phases for each enabled ABI, or is there some way for the ebuild to indicate whether or not its phases need to be executed for each enabled ABI? This is dynamicly checked at runtime, no need to modify the ebuilds and also no needless compilation, when there is no ABI-specific content. A more detailed answer at package manager level: After the src_install phase for the first requested ABI has been finished, the content of $DESTDIR is checked. If there is no ABI specific content, the other enabled ABIs are skipped and the following steps are done as usual. I think it would be helpful to include a short explanation of these kinds of details in the GLEP, in order to help people wrap their heads around the whole thing (possibly avoiding the Huh? kind of reaction that you got from Brian). -- Thanks, Zac
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 02:52 PM, Zac Medico wrote: On 07/01/2012 02:39 PM, Matt Turner wrote: On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. I dont follow. Did you think about only having additional ABI flags for certain cases? Right. It seems to me that not having the ABI flags for packages like x11-proto/* would make more sense, but may be more work to implement. It seems like this could easily be controlled by setting a PROPERTIES or RESTRICT value in the ebuild. Also, it might be useful to give the ebuild similar control over the abiwrapper flag via PROPERTIES or RESTRICT. On irc, I asked Tommy about the abiwrapper thing, and he suggested to set IUSE=+abiwrapper for packages containing programs like qmake which are known to produce ABI specific output. -- Thanks, Zac
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On 07/01/2012 02:34 PM, Thomas Sachau wrote: Zac Medico schrieb: On 07/01/2012 04:29 AM, Thomas Sachau wrote: Matt Turner schrieb: On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau to...@gentoo.org wrote: I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. If a package has dependencies, then those dependencies are required to have at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? All packages do get the ABI flags (with the needed EAPI or via enabled portage feature, which is currently in the multilib branch). If a package does not install anything ABI-specific (no headers, no libs and no binaries), then there is no overhead, since it will just get compiled/installed for one ABI, even if multiple ABI flags are enabled. For a package like this that does not install anything ABI-specific, does the package manager still execute phases for each enabled ABI, or is there some way for the ebuild to indicate whether or not its phases need to be executed for each enabled ABI? This is dynamicly checked at runtime, no need to modify the ebuilds and also no needless compilation, when there is no ABI-specific content. A more detailed answer at package manager level: After the src_install phase for the first requested ABI has been finished, the content of $DESTDIR is checked. If there is no ABI specific content, the other enabled ABIs are skipped and the following steps are done as usual. In case anyone want some more detail, here's a follow-up question from irc: zmedico Tommy[D]: does any ELF executable qualify as abi specific and trigger builds for all ABIs? Tommy[D] zmedico: if it goes into any of /bin /usr/bin /sbin /usr/sbin and you enable the abiwrapper USE flag, yes, otherwise you just request a binary for the default ABI, so no need to rebuild everything for no need -- Thanks, Zac
[gentoo-dev] freebsd.eclass change
I want to add freebsd_get_cpuarch() to freebsd.eclass. This will give us a platform-independent way of generating MACHINE_CPUARCH, which will make building FreeBSD components on other platforms (i.e. Linux and Prefix) easier. --- freebsd.eclass.old 2012-07-01 19:15:56.157277000 -0400 +++ freebsd.eclass 2012-07-01 19:44:08.093698000 -0400 @@ -58,6 +58,24 @@ freebsd_get_bmake() { echo ${bmake} } +freebsd_get_cpuarch() { + local arch=$(uname -m) + case $(uname -m) in + x86_64) + return 'amd64';; + arm*) + return 'arm';; + i?86) + return 'i386';; + ppc*) + return 'powerpc';; + mips*) + return 'mips';; + sparc*) + return 'sparc';; + *) + return arch; + esac +} + freebsd_do_patches() { if [[ ${#PATCHES[@]} -gt 1 ]] ; then for x in ${PATCHES[@]}; do Does anyone have any objections? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: freebsd.eclass change
There is a small error in this. It should be 's/return/echo/'. On 07/01/2012 07:48 PM, Richard Yao wrote: I want to add freebsd_get_cpuarch() to freebsd.eclass. This will give us a platform-independent way of generating MACHINE_CPUARCH, which will make building FreeBSD components on other platforms (i.e. Linux and Prefix) easier. --- freebsd.eclass.old 2012-07-01 19:15:56.157277000 -0400 +++ freebsd.eclass 2012-07-01 19:44:08.093698000 -0400 @@ -58,6 +58,24 @@ freebsd_get_bmake() { echo ${bmake} } +freebsd_get_cpuarch() { + local arch=$(uname -m) + case $(uname -m) in + x86_64) + return 'amd64';; + arm*) + return 'arm';; + i?86) + return 'i386';; + ppc*) + return 'powerpc';; + mips*) + return 'mips';; + sparc*) + return 'sparc';; + *) + return arch; + esac +} + freebsd_do_patches() { if [[ ${#PATCHES[@]} -gt 1 ]] ; then for x in ${PATCHES[@]}; do Does anyone have any objections? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-07-01 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-07-01 23h59 UTC. Removals: sys-cluster/lam-mpi 2012-06-25 16:35:34 jsbronder net-fs/leechcraft-vrooby2012-07-01 13:41:43 maksbotan Additions: app-text/leechcraft-monocle 2012-06-26 17:01:34 maksbotan dev-python/doit 2012-06-27 08:03:32 yngwin www-apps/nikola 2012-06-27 08:07:33 yngwin net-misc/openvswitch2012-06-27 08:49:35 dev-zero media-video/subdownloader 2012-06-27 09:38:16 tampakrap x11-misc/slimlock 2012-06-27 14:22:51 titanofold www-servers/servefile 2012-06-27 19:28:40 sping games-board/domination 2012-06-28 05:36:39 mr_bones_ dev-python/sphinxcontrib-googleanalytics2012-06-28 19:36:52 floppym dev-python/g-pypi 2012-06-28 19:48:16 floppym media-gfx/nomacs2012-06-29 07:37:18 yngwin x11-misc/qlipper2012-06-29 07:47:52 yngwin dev-python/bitarray 2012-06-29 11:39:43 jlec net-fs/leechcraft-vrooby2012-06-29 19:37:26 maksbotan virtual/leechcraft-storage-device-manager 2012-06-29 19:43:32 maksbotan app-arch/innoextract2012-06-29 21:26:51 hasufell games-rpg/arx-libertatis2012-06-29 21:47:41 hasufell games-rpg/arx-fatalis-data 2012-06-29 21:48:09 hasufell games-rpg/arx-fatalis-demo 2012-06-29 21:48:35 hasufell net-misc/grive 2012-06-30 00:56:07 ottxor media-libs/libsbsms 2012-06-30 04:02:48 radhermit net-news/rssguard 2012-06-30 09:11:12 yngwin net-news/quiterss 2012-06-30 09:31:38 yngwin dev-ml/pa_ounit 2012-06-30 14:35:38 aballier dev-ml/variantslib 2012-06-30 14:44:29 aballier dev-ml/pipebang 2012-06-30 14:49:17 aballier sys-fs/leechcraft-vrooby2012-07-01 13:36:56 maksbotan app-crypt/hashcat-bin 2012-07-01 22:41:56 zerochaos -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: sys-cluster/lam-mpi,removed,jsbronder,2012-06-25 16:35:34 net-fs/leechcraft-vrooby,removed,maksbotan,2012-07-01 13:41:43 Added Packages: app-text/leechcraft-monocle,added,maksbotan,2012-06-26 17:01:34 dev-python/doit,added,yngwin,2012-06-27 08:03:32 www-apps/nikola,added,yngwin,2012-06-27 08:07:33 net-misc/openvswitch,added,dev-zero,2012-06-27 08:49:35 media-video/subdownloader,added,tampakrap,2012-06-27 09:38:16 x11-misc/slimlock,added,titanofold,2012-06-27 14:22:51 www-servers/servefile,added,sping,2012-06-27 19:28:40 games-board/domination,added,mr_bones_,2012-06-28 05:36:39 dev-python/sphinxcontrib-googleanalytics,added,floppym,2012-06-28 19:36:52 dev-python/g-pypi,added,floppym,2012-06-28 19:48:16 media-gfx/nomacs,added,yngwin,2012-06-29 07:37:18 x11-misc/qlipper,added,yngwin,2012-06-29 07:47:52 dev-python/bitarray,added,jlec,2012-06-29 11:39:43 net-fs/leechcraft-vrooby,added,maksbotan,2012-06-29 19:37:26 virtual/leechcraft-storage-device-manager,added,maksbotan,2012-06-29 19:43:32 app-arch/innoextract,added,hasufell,2012-06-29 21:26:51 games-rpg/arx-libertatis,added,hasufell,2012-06-29 21:47:41 games-rpg/arx-fatalis-data,added,hasufell,2012-06-29 21:48:09 games-rpg/arx-fatalis-demo,added,hasufell,2012-06-29 21:48:35 net-misc/grive,added,ottxor,2012-06-30 00:56:07 media-libs/libsbsms,added,radhermit,2012-06-30 04:02:48 net-news/rssguard,added,yngwin,2012-06-30 09:11:12 net-news/quiterss,added,yngwin,2012-06-30 09:31:38 dev-ml/pa_ounit,added,aballier,2012-06-30 14:35:38 dev-ml/variantslib,added,aballier,2012-06-30 14:44:29 dev-ml/pipebang,added,aballier,2012-06-30 14:49:17 sys-fs/leechcraft-vrooby,added,maksbotan,2012-07-01 13:36:56 app-crypt/hashcat-bin,added,zerochaos,2012-07-01 22:41:56 Done.
[gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/01/2012 05:39 PM, Matt Turner wrote: On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. I dont follow. Did you think about only having additional ABI flags for certain cases? Right. It seems to me that not having the ABI flags for packages like x11-proto/* would make more sense, but may be more work to implement. For x11-proto/* you currently do need to build the package for each individual ABI because they install a file in /usr/$(get_libdir)/pkgconfig. This should probably be changed upstream to install to /usr/share/pkgconfig, as there is nothing ABI-specific in there. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJP8O8VAAoJELHSF2kinlg4uToP/1swJ2Dm0W1R5z15L41kCO8F jKtc1Q+3xN/gfDuHzAR1rJpzNLGhOzX0tE+9TKePp4TLcoDKSIeOi9wR+MwncULE aOqIDPQE5n06z06FEuKqkyWUSJZjJ3sObWiH0+hhWssIorks+LEVYZ8EeLNCw0rb 4zmobbckGeMcbZvcvtISw/N7K3QuUoEDM5rj+059ViqShLxzZegEnO8WU/+h1qi7 E6G5PwKK2MhMGHdWT/Gt+yMT6bSQbNpHu78YHElQFuYSagCcBe75JMfjTKup5iu+ 15hM7ZBbiU6yyx45CV6SSXzdqdpkTBkWY7lfrMzXqa3ZtIqgDhmtdxZiNyJ0sHDe dOtYhJC2FGIGkgv3ZarCEqlybOHrgFxYfBSo0dyFzbr9bWebJgb+mg8CWVbNb4j4 3pe3jVOy5r0CNQ6/ZKRN2ZhzMBhjB0sIsoVmnAOFyqKMNCXHTBHNngQ3jMdxkrJD fhBVMkEnRr2Gmzmsgi1DZZMvRI9W/6SJo03zwYrik0VBBqyRubRRvEp7mNJO1kV/ eW+8tfStDyOHXuQherGJfCdZiHdP6puj4ZmySURhFHAyeRTEQ1Gxq+vPDIGed1Jv 23odxq+l4MW9lktPgUIrTeku4zUG//FWva74JPBUld1VyicINSCU7plFkLwF5z0o XEzrHuDZRO+k9Vdi5y1P =RrNC -END PGP SIGNATURE-