August 2016 - Devel - oVirt List Archives

Alternatives to automatically move bugs to MODIFIED
by Yedidyah Bar David 14 Sep '16

14 Sep '16

Hi all, We currently have a bot that automatically moves bugs from POST to MODIFIED if all linked patches on gerrit are merged. It happened to me personally several times that this was a wrong thing to do, either because a new patch was still needed but not pushed yet, or because an existing patch should have been back-ported to another branch and wasn't yet. Since I usually pay more attention to my bug in POST, I sometimes missed this and handled the missing patches (backports, usually) later than I could if left on POST. I have a feeling I am not the only one. So I suggest to stop doing this. I can think of several alternatives: 1. Do nothing. I think that's reasonable - I think most people pay more attention to POST bugs anyway. 2. Set needinfo on bug owner. 3. Send some alert email to relevant people (bug owner, existing patches owners, perhaps others - e.g. reviewers of existing patches, perhaps those that actually reviewed, etc.). Need to think how to make it not too annoying for others but still effective also if owner is on long PTO or something like that. New flag doesn't have to be very specific - can be called something like 'attention needed' or something like that. 4. Add a new flag for that and set it. This will allow easier filtering/reporting. What do you think? -- Didi

8 17

CentOS Virt SIG - aarch 64 and ppc64le support
by Sandro Bonazzola 14 Sep '16

14 Sep '16

Hi, within CentOS Virt SIG interest in having ppc64le and aarch64 as supported architecture in oVirt has raised. Packages from oVirt 4.0.2 has been built for both architectures for hypervisor host side. You can find the rpms in the cbs repositories waiting to be signed and published to mirrors here: - QEMU and deps: https://cbs.centos.org/repos/virt7-kvm-common-release/ - oVirt Common deps: https://cbs.centos.org/repos/virt7-ovirt-common-release/ - oVirt 4.0 specific packages: https://cbs.centos.org/repos/virt7-ovirt-40-release/ While I'm pretty sure ppc64le will work out of the box I think we're missing something on engine side in order to fully support aarch64. Michal, Francesco, can you open relevant BZs in order to get aarch64 fully supported? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 4

possible bug in libgovirt or oVirt 4.0.2
by i iordanov 05 Sep '16

05 Sep '16

Hello, I just tested oVirt 4.0.2 with Opaque, and when I try to make the following call: ovirt_vm_start(vm, proxy, &error); I get an error->message: "Could not find 'state' node". Further on, when I attempt to make a call to: ovirt_vm_get_ticket(vm, proxy, &error) I get the same error message "Could not find 'state' node". Indeed, on oVirt 4.0.2, when I browse to: https://livecd.localdomain/ovirt-engine/api/vms/VM_ID_HERE I see no "state" node, only "<status>up</status>" On the other hand, when I browse to the same part of the API on oVirt 3.4, I see: "<status><state>up</state></status>" Seems to me the API changed but the libgovirt, the client C library did not. I hope you can correct this soon, and thanks in advance! Cheers, iordan -- The conscious mind has only one thread of execution.

2 1

[ANN] oVirt 4.0.4 First Release Candidate is now available
by Sandro Bonazzola 01 Sep '16

01 Sep '16

The oVirt Project is pleased to announce the availability of the First Release Candidate of oVirt 4.0.4 for testing, as of August 31st, 2016. This release is available now for: * Fedora 23 (tech preview) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 (tech preview) * oVirt Next Generation Node 4.0 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This update is the first release candidate of the fourth in a series of stabilization updates to the 4.0 series. 4.0.4 brings 7 enhancements and 93 bugfixes, including 33 high or urgent severity fixes, on top of oVirt 4.0 series See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is available. [4] * A new oVirt Next Generation Node is available [4]. * A new oVirt Engine Appliance is available for Red Hat Enterprise Linux and CentOS Linux (or similar) * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.4 release highlights: http://www.ovirt.org/release/4.0.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.4/ [4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

oVirt Engine 4.0.4 branched
by Tal Nisan 30 Aug '16

30 Aug '16

Hi everyone, We've created ovirt-engine-4.0.4 branch this morning from the 4.0.3 branch. >From now on 4.0.4 Engine patches will have to be backported to the new branch after being backported to the ovirt-engine-4.0 branch. Engine 4.0.5 patches can now be backported to ovirt-engine-4.0 branch. Tal.

3 4

repos down
by Gary Pedretty 30 Aug '16

30 Aug '16

--Apple-Mail=_A85252B1-0D2F-4BC6-948C-BDA2E4E5E66B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am unable to do any installs, yum cannot access the mirrors list =E2=80=9CCould not retrieve mirrorlist = http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7=E2=80=9D = error was 12: Timeout on = http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7: (28, = =E2=80=98Connection timed out after 30001 milliseconds=E2=80=99)" Tried from various locations on different ISPs. Gary ------------------------------------------------------------------------ Gary Pedretty gary(a)ravnalaska.net = <mailto:gary@eraalaska.net> Systems Manager www.flyravn.com = <http://www.flyravn.com/> Ravn Alaska /\ 907-450-7251 5245 Airport Industrial Road / \/\ 907-450-7238 fax Fairbanks, Alaska 99709 /\ / \ \ Second greatest commandment Serving All of Alaska / \/ /\ \ \/\ =E2=80=9CLove your = neighbor as Really loving the record green up date! Summmer!! yourself=E2=80=9D = Matt 22:39 ------------------------------------------------------------------------ --Apple-Mail=_A85252B1-0D2F-4BC6-948C-BDA2E4E5E66B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I am unable to do any installs, yum cannot access the mirrors = list<div class=3D""><br class=3D""></div><div class=3D"">=E2=80=9CCould = not retrieve mirrorlist <a = href=3D"http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7" = class=3D"">http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el= 7</a>=E2=80=9D error was</div><div class=3D"">12: Timeout on <a = href=3D"http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el7:"= = class=3D"">http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.0-el= 7:</a> (28, =E2=80=98Connection timed out after 30001 = milliseconds=E2=80=99)"</div><div class=3D""><br class=3D""></div><div = class=3D"">Tried from various locations on different ISPs.</div><div = class=3D""><br class=3D""></div><div class=3D"">Gary</div><div = class=3D""><br class=3D""><div class=3D""> <div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: = auto; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"orphans: auto; text-align: start; text-indent: = 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D""><div style=3D"orphans: = auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;" class=3D""><div style=3D"orphans: auto; text-align: = start; text-indent: 0px; widows: auto; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"orphans: auto; text-align: start; text-indent: = 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D""><div style=3D"orphans: = auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;" class=3D""><div style=3D"orphans: auto; text-align: = start; text-indent: 0px; widows: auto; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div style=3D"orphans: auto; text-align: start; text-indent: = 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space;" class=3D""><font face=3D"Menlo" = style=3D"color: rgb(0, 0, 0); font-size: 12px; letter-spacing: normal; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><div = class=3D"">---------------------------------------------------------------= ---------</div><div class=3D"">Gary Pedretty         =                     =            <a = href=3D"mailto:gary@eraalaska.net" = class=3D"">gary(a)ravnalaska.net</a></div><div class=3D"">Systems Manager =                     =                     =  <a href=3D"http://www.flyravn.com" = class=3D"">www.flyravn.com</a></div><div class=3D"">Ravn Alaska   =                     =     /\                 =    907-450-7251</div><div class=3D"">5245 Airport Industrial = Road         /  \/\         =     907-450-7238 fax</div><div class=3D"">Fairbanks, Alaska =  99709        /\  /    \ \ = Second greatest commandment</div></font><font face=3D"Monaco" = class=3D""><span style=3D"font-size: 12px;" class=3D"">Serving All of = Alaska          /  \/  /\  \ \/\ =   =E2=80=9CLove your neighbor as</span></font><br = style=3D"font-family: Monaco;" class=3D""><font face=3D"Menlo" = style=3D"color: rgb(0, 0, 0); letter-spacing: normal; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px;" class=3D""><span style=3D"font-size: 12px;" class=3D"">Really = loving the record green up date! Summmer!!   yourself=E2=80=9D M= att 22:39</span></font><div style=3D"color: rgb(0, 0, 0); = letter-spacing: normal; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: Menlo;" = class=3D""></div><font face=3D"Menlo" style=3D"font-size: 12px;" = class=3D""></font><span style=3D"color: rgb(0, 0, 0); letter-spacing: = normal; text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; font-size: 12px;" class=3D""><font = face=3D"Menlo" class=3D""><div = class=3D"">---------------------------------------------------------------= ---------</div></font></span><div style=3D"color: rgb(0, 0, 0); = letter-spacing: normal; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><font = face=3D"Menlo" style=3D"font-size: 12px;" class=3D""><br = class=3D""></font></div></div><span style=3D"color: rgb(0, 0, 0); = letter-spacing: normal; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; font-size: 12px;" = class=3D""><br class=3D"Apple-interchange-newline"></span></div><span = style=3D"color: rgb(0, 0, 0); letter-spacing: normal; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; font-size: 12px;" class=3D""><br = class=3D"Apple-interchange-newline"></span></div><span style=3D"color: = rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-size: = 12px;" class=3D""><br class=3D"Apple-interchange-newline"></span></div><br= class=3D"Apple-interchange-newline"></div><br = class=3D"Apple-interchange-newline"></div><br = class=3D"Apple-interchange-newline"></div><br = class=3D"Apple-interchange-newline"></div><br = class=3D"Apple-interchange-newline"></div><br = class=3D"Apple-interchange-newline"><br = class=3D"Apple-interchange-newline"> </div> <br class=3D""></div></body></html>= --Apple-Mail=_A85252B1-0D2F-4BC6-948C-BDA2E4E5E66B--

3 2

oVirt 4.0.4 RC1 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola 29 Aug '16

29 Aug '16

All stable branch maintainers, please make sure to - merge all relevant open bugs until Tuesday morning 11:00 AM TLV time. For each package that need to be built (i.e oVirt product) please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.4, tr: 4.0.4) A list of bugs that require attention is here: - https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

1 0

oVirt 4.0.4 RC1 build planned
by Sandro Bonazzola 29 Aug '16

29 Aug '16

Fyi oVirt developers, An oVirt build is planned for this Tuesday 11:00 AM TLV time (10:00 AM CEST). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Monday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Tuesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0. <https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.…> 4 <https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.…> %20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost <https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.…> -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

1 0

broken master: removal of release in spec requirements
by Yaniv Bronheim 29 Aug '16

29 Aug '16

Hi, In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading. "yum install vdsm" will eventually cause this mixup as vdsm won't require the newer vdsm-python I think this change should be reverted and the solution should be in the build process. Newer release is equal to higher version, requirement should include the release number. so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so 4.18.7-2 is newer. can't see how this can be different. e.g for the bug: =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Removing: vdsm x86_64 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 2.7 M vdsm-api noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 325 k vdsm-cli noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 342 k vdsm-hook-vmfex-dev noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 21 k vdsm-jsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 81 k vdsm-python noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 2.4 M vdsm-xmlrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 109 k vdsm-yajsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 95 k Problem. -- *Yaniv Bronhaim.*

4 5

Re: [ovirt-devel] [libvirt] RFC: Limited dynamic ownership
by Martin Kletzander 29 Aug '16

29 Aug '16

--R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Tue, Aug 23, 2016 at 07:25:56PM -0400, Daniel P. Berrange wrote: >On Tue, Aug 23, 2016 at 06:17:44PM -0400, Martin Kletzander wrote: >> On Tue, Aug 23, 2016 at 05:54:29PM -0400, Daniel P. Berrange wrote: >> > On Tue, Aug 23, 2016 at 05:06:20PM -0400, Martin Kletzander wrote: >> > > Hi everyone, >> > > >> > > so there was an idea about limiting the relabelling of images that >> > > libvirt does. And I'm taking the liberty of pitching my idea how to >> > > approach this. I feel like it's pretty simple thing and there's not >> > > much to talk about, but a) I could've missed something and b) you might >> > > hate the way I approach it. >> > > >> > > The idea is to extend the seclabel XML, for example: >> > > >> > > <seclabel type='dynamic' model='dac' relabel='whitelist'> >> > > <path>/var/lib/libvirt/images</path> >> > > <path>/data/virt-stuff</path> >> > > </seclabel> >> > > >> > > Either we allow 'relabel' to be set to 'whitelist' or add a new >> > > attribute with a name like 'mode' or something, which will control how >> > > we relabel the files (actually relabel='no' can mean 'whitelist' and >> > > relabel='yes' can mean blacklist without adding anything there). After >> > > that you can specify what paths are (dis)allowed to be labelled. >> > > >> > > Actually thinking about it I like the following the most: >> > > >> > > <seclabel type='dynamic' model='dac' relabel='no'> >> > > <whitelist path='/data'/> >> > > <blacklist path='/data/private/non-virt/stuff'/> >> > > </seclabel> >> > > >> > > which I believe is pretty explanatory. Feel free to ask if it's not. >> > > And let me know what you think. >> > >> > I don't think we need to get involved in the <seclabel> configuration. >> > >> >> I forgot to mention that I like that because you would be able to >> specify this per-disk as well as for the whole VM. > >Of course using info in <disk> directly achieves the same thing > >> > We've already got the ability in the <disk> config to provide the >> > full backing chain explicitly. If a management app provides a full >> > backing chain in the XML, we could validate the app provided chain >> > against the chain we probe and report error if they mis-match. (Maybe >> > we in fact already report this?) >> > >> >> Not yet: >> >> "It is currently ignored on input and only used for output to describe >> the detected backing chains of running domains." >> >> It would help with this, but I don't feel like it's that usable. Also >> I feel like everyone will overuse that while misunderstanding what it >> actually does. Also if you do some block-merge or whatever, you need to >> update the backing chain and everyone will just re-probe it because no >> management layer likes keeping more information than needed. > >If you provide the <seclabel> whitelist though, you're essentially >going to want to provide the same info that you would provide with >the <backing> data, as the whitelist you're providing there is >essentially trying to whitelist only the expected backing file. > >I don't feel like we should be inventing new seclabel elements to >duplicate info we could already provide via existing backing data >elements. > It just introduces more complexity that might result in more bugs, but yes, it is information duplication. >> > Thinking bout this in the context of a recent OpenStack Nova CVE, >> > where Nova mistakenly set format=qcow2, instead of format=raw, allowing >> > a malicious guest to write a qcow2 header with backing file. If Nova >> > had provided the full backing chain it expected (no backing chain at >> > all), then libvirt would have seen the maliciously created backing >> > chain, and caught the problem despite Nova giving the wrong format. >> > >> > >> > Separately from this, in the context of storage pools, when giving >> > a <disk type=pool> in the domain XML, we could do validation to >> > ensure the backing file of the volume always pointed to a volume >> > that was also inside a storage pool. This would allow us to have >> > backing files pointing to volumes in different storage pools, but >> > would prevent them pointing to arbitrary files that were not in >> > storage pools at all (eg /etc/password, or /dev/root, etc). >> > >> >> That is good idea, but it won't cover all the cases, for example if >> you're not using storage pools. > >Yep, at least from OpenStack POV our goal is to switch 100% to using >storage pools. > >For non-storage pool deployments though, I think it is common that >the mgmt app will have a specific place where it will always put >disks. eg on OpenStack file based disks will always live under >/var/lib/nova/instances. > >So if there was a qemu.conf setting to whitelist allowed disk image >locations, we could lock down where we permit relabelling for the >openstack host as a whole, and not need to change anything on a per >guest basis. > I like the per-guest approach better, but qemu.conf is satisfactory enough, I guess. >> It could be nice to get feedback from upper mgmt layers, any idea where >> else to post this questions? > >ovirt might have feedback i guess > Cc'd ovirt-devel, even though I don't think they use it (or at least not yet). If you feel like it, don't hesitate to Cc appropriate OpenStack list as well (if that's not much cross-posting). Martin >Regards, >Daniel >-- >|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| >|: http://libvirt.org -o- http://virt-manager.org :| >|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| >|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXw/4jAAoJEAgfwp8kF4bdEV4P/1JP07oQ2ug+sGs5CImqbJak 6eajVCCcobapZgT7rDWbla5e2G5XMdzbV1vVzuIl2OVo4rGmcLuZjozVH8dewg0M tEjWLenbciXnUcqIrEA8PTP5qAdEAdVUZ/7kwFT3shRjTUOEYk46BM+fiRWz/pQM DI/xaPpXcZarfohLOGUgdRv+00shQPVZFg786FXBL+aYNFwTfbFDOnboYEYwKhq2 WGHG0PWLF3iIBlJWBFs4Nz1pQ48cw4CGWmXcOGtusIiqud5FsbKjNX+s64PDY1Yz 8UzC4c9+4LyqobUJp5EulsAmXedKK0bTxs4GI/eePkHZfBaRuOJtshbY2iETljsS Ce1s9Y3gpfP6UzAZImOa67F2rms9Fgv8Mm4pRnG2l/FTCvFSq7Grn8pPKL12jWAN Ti6hOQGCX45h8lN17zfERlWWPBFk3Mtw3L8bbh8Ja0xhYgsH0qS1mdeE/VmjKKFC OqZvT9GgtwFg4t77nHCIhFBSTEc3DoV6lNMrPxaTVswXCKSlYJAz2IUd8DFN5FFF 71WlKgvCKWl6iqo2FpxklhqfsUNSL6J31Kgh29r54qYcNZc1oobWsyJAqyeQcpER 3nHyY14QhIDc2LojcEisGXyPErtHZiVfexlB++Ap2O5W3tkxH08yWnV0Cd2J+CK2 MLB3K7JjrEt84oY8EGP8 =JNYW -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk--

1 0