From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DA7C8C001DC for ; Thu, 27 Jul 2023 20:35:30 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 88F2D8687A; Thu, 27 Jul 2023 22:35:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="rOKaXIBe"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9A3DC86849; Thu, 27 Jul 2023 22:35:26 +0200 (CEST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6FC05867D8 for ; Thu, 27 Jul 2023 22:35:21 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-4476f713e15so34894137.3 for ; Thu, 27 Jul 2023 13:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; t=1690490120; x=1691094920; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=i3xFk3JHkslXCCWZnJgPcEky8Atoaul+v3e1tOIqcno=; b=rOKaXIBeipGxpZlRLdcEvpXkGnkMy4aTTJCWog/gGC+qvbZeayUkWJ5EjI8sMFclK8 z55wORhnSdHHw9WyK9RjvRTt0fV9Vlv/xBDGXJ3Hzw8AWE4N52iENnsgreCy4KNyRgsE xEO+rCa87jGUUGwO/BaDLk0nq+XtEBLi2DRQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690490120; x=1691094920; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=i3xFk3JHkslXCCWZnJgPcEky8Atoaul+v3e1tOIqcno=; b=fJ99Bev5l3IYE0CO6zeEAnFmaKyAAfVOCgoyJ6aAFgl+40lbkh6n8d1Ko9By2eNR8l MACclijnYoaoSkLoJgb+qDi24cHHEGHDLD3lmFSCmtGcbvii5P2KNggT8+tgnrtZ6et3 O/6OdW8zXAqZKjnef4BwvGReWo8+OJfIiVrWCJQbRk1DMinIRFA1FilaxAPY34JHx8is cpFq71cLuCv8eTivqtDpzbsO5H0xw1q/HwYAXRh99s2WCr55yKzQ+k02wJ+n/imx3TbI p3MYfWj41+wFQp/siqiNhQwkTRpNoFB/MGY5XmTzU1zWyk+9zGXgXX1ld0Z+QTtQKfcx MbUA== X-Gm-Message-State: ABy/qLZALdlVm5LfMky7my72hCiFGMeqfPXKaeb+7noumWtPQs6QEcJx zHbSYZAuHaS4WvTu82eFL3edvQ== X-Google-Smtp-Source: APBJJlEx8PQWgY4OTYaYz8TWIXYdN73M2TlgHv3IEj+V2DlMYA2T+qbj15jJRMLLoLJkU6GgLMV88Q== X-Received: by 2002:a05:6102:94:b0:447:6947:24dc with SMTP id t20-20020a056102009400b00447694724dcmr590134vsp.9.1690490119947; Thu, 27 Jul 2023 13:35:19 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-96a7-b348-5b90-69b9.res6.spectrum.com. [2603:6081:7b00:6400:96a7:b348:5b90:69b9]) by smtp.gmail.com with ESMTPSA id f24-20020a67e098000000b0043d5d6eb61fsm350540vsl.31.2023.07.27.13.35.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jul 2023 13:35:18 -0700 (PDT) Date: Thu, 27 Jul 2023 16:35:15 -0400 From: Tom Rini To: Simon Glass Cc: u-boot@lists.denx.de Subject: Re: [PATCH] CI: Add automatic retry for test.py jobs Message-ID: <20230727203515.GN3630934@bill-the-cat> References: <20230712023303.1969966-1-trini@konsulko.com> <20230712170859.GA2066889@bill-the-cat> <20230712203839.GJ2066889@bill-the-cat> <20230713215740.GP2066889@bill-the-cat> <20230716181758.GT2066889@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2y/BLb0xFBL7vslz" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean --2y/BLb0xFBL7vslz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 27, 2023 at 01:18:12PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Sun, 16 Jul 2023 at 12:18, Tom Rini wrote: > > > > On Sat, Jul 15, 2023 at 05:40:25PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 13 Jul 2023 at 15:57, Tom Rini wrote: > > > > > > > > On Thu, Jul 13, 2023 at 03:03:57PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Wed, 12 Jul 2023 at 14:38, Tom Rini wrote: > > > > > > > > > > > > On Wed, Jul 12, 2023 at 02:32:18PM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Wed, 12 Jul 2023 at 11:09, Tom Rini w= rote: > > > > > > > > > > > > > > > > On Wed, Jul 12, 2023 at 08:00:23AM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Tue, 11 Jul 2023 at 20:33, Tom Rini wrote: > > > > > > > > > > > > > > > > > > > > It is not uncommon for some of the QEMU-based jobs to f= ail not because > > > > > > > > > > of a code issue but rather because of a timing issue or= similar problem > > > > > > > > > > that is out of our control. Make use of the keywords th= at Azure and > > > > > > > > > > GitLab provide so that we will automatically re-run the= se when they fail > > > > > > > > > > 2 times. If they fail that often it is likely we have f= ound a real issue > > > > > > > > > > to investigate. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Tom Rini > > > > > > > > > > --- > > > > > > > > > > .azure-pipelines.yml | 1 + > > > > > > > > > > .gitlab-ci.yml | 1 + > > > > > > > > > > 2 files changed, 2 insertions(+) > > > > > > > > > > > > > > > > > > This seems like a slippery slope. Do we know why things f= ail? I wonder > > > > > > > > > if we should disable the tests / builders instead, until = it can be > > > > > > > > > corrected? > > > > > > > > > > > > > > > > It happens in Azure, so it's not just the broken runner pro= blem we have > > > > > > > > in GitLab. And the problem is timing, as I said in the comm= it. > > > > > > > > Sometimes we still get the RTC test failing. Other times we= don't get > > > > > > > > QEMU + U-Boot spawned in time (most often m68k, but sometim= es x86). > > > > > > > > > > > > > > How do we keep this list from growing? > > > > > > > > > > > > Do we need to? The problem is in essence since we rely on free > > > > > > resources, sometimes some heavy lifts take longer. That's what= this > > > > > > flag is for. > > > > > > > > > > I'm fairly sure the RTC thing could be made deterministic. > > > > > > > > We've already tried that once, and it happens a lot less often. If = we > > > > make it even looser we risk making the test itself useless. > > > > > > For sleep, yes, but for rtc it should be deterministic now...next time > > > you get a failure could you send me the trace? > > > > Found one: > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3D6592&view= =3Dlogs&j=3Db6c47816-145c-5bfe-20a7-c6a2572e6c41&t=3D0929c28c-6e32-5635-962= 4-54eaa917d713&l=3D599 >=20 > I don't seem to have access to that...but it is rtc or sleep? It was the RTC one, and has since rolled off and been deleted. > > And note that we have a different set of timeout problems that may or m= ay not > > be configurable, which is in the upload of the pytest results. I haven'= t seen > > if there's a knob for this one yet, within Azure (or the python project= we're > > adding for it). >=20 > Oh dear. >=20 > > > > > > > The spawning thing...is there a timeout for that? What actually f= ails? > > > > > > > > It doesn't spawn in time for the framework to get to the prompt. We > > > > could maybe increase the timeout value. It's always the version te= st > > > > that fails. > > > > > > Ah OK, yes increasing the timeout makes sense. > > > > > > > > > > > > > > > > I'll note that we don't have this problem with sandbox te= sts. > > > > > > > > > > > > > > > > OK, but that's not relevant? > > > > > > > > > > > > > > It is relevant to the discussion about using QEMU instead of = sandbox, > > > > > > > e.g. with the TPM. I recall a discussion with Ilias a while b= ack. > > > > > > > > > > > > I'm sure we could make sandbox take too long to start as well, = if enough > > > > > > other things are going on with the system. And sandbox has its= own set > > > > > > of super frustrating issues instead, so I don't think this is a= great > > > > > > argument to have right here (I have to run it in docker, to get= around > > > > > > some application version requirements and exclude event_dump, b= ootmgr, > > > > > > abootimg and gpt tests, which could otherwise run, but fail for= me). > > > > > > > > > > I haven't heard about this before. Is there anything that could b= e done? > > > > > > > > I have no idea what could be done about it since I believe all of t= hem > > > > run fine in CI, including on this very host, when gitlab invokes it > > > > rather than when I invoke it. My point here is that sandbox tests a= re > > > > just a different kind of picky about things and need their own kind= of > > > > "just hit retry". > > > > > > Perhaps this is Python dependencies? I'm not sure, but if you see it > > > again, please let me know in case we can actually fix this. > > > > Alright. So the first pass I took at running sandbox pytest with as > > little hand-holding as possible I hit the known issue of /boot/vmlinu* > > being 0400 in Ubuntu. I fixed that and then re-ran and: > > test/py/tests/test_cleanup_build.py F > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FAILURES =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _________________________________________ test_clean __________________= ________________________ > > test/py/tests/test_cleanup_build.py:94: in test_clean > > assert not leftovers, f"leftovers: {', '.join(map(str, leftovers))}" > > E AssertionError: leftovers: fdt-out.dtb, sha1-pad/sandbox-u-boot.dtb= , sha1-pad/sandbox-kernel.dtb, sha1-basic/sandbox-u-boot.dtb, sha1-basic/sa= ndbox-kernel.dtb, sha384-basic/sandbox-u-boot.dtb, sha384-basic/sandbox-ker= nel.dtb, algo-arg/sandbox-u-boot.dtb, algo-arg/sandbox-kernel.dtb, sha1-pss= /sandbox-u-boot.dtb, sha1-pss/sandbox-kernel.dtb, sha256-pad/sandbox-u-boot= =2Edtb, sha256-pad/sandbox-kernel.dtb, sha256-global-sign/sandbox-binman.dt= b, sha256-global-sign/sandbox-u-boot.dtb, sha256-global-sign/sandbox-u-boot= -global.dtb, sha256-global-sign/sandbox-kernel.dtb, sha256-global-sign-pss/= sandbox-binman-pss.dtb, sha256-global-sign-pss/sandbox-u-boot.dtb, sha256-g= lobal-sign-pss/sandbox-kernel.dtb, sha256-global-sign-pss/sandbox-u-boot-gl= obal-pss.dtb, auto_fit/dt-1.dtb, auto_fit/dt-2.dtb, sha256-pss/sandbox-u-bo= ot.dtb, sha256-pss/sandbox-kernel.dtb, sha256-pss-pad/sandbox-u-boot.dtb, s= ha256-pss-pad/sandbox-kernel.dtb, hashes/sandbox-kernel.dtb, sha256-basic/s= andbox-u-boot.dtb, sha256-basic/sandbox-kernel.dtb, sha1-pss-pad/sandbox-u-= boot.dtb, sha1-pss-pad/sandbox-kernel.dtb, sha384-pad/sandbox-u-boot.dtb, s= ha384-pad/sandbox-kernel.dtb, sha256-pss-pad-required/sandbox-u-boot.dtb, s= ha256-pss-pad-required/sandbox-kernel.dtb, ecdsa/sandbox-kernel.dtb, sha256= -pss-required/sandbox-u-boot.dtb, sha256-pss-required/sandbox-kernel.dtb > > E assert not [PosixPath('fdt-out.dtb'), PosixPath('sha1-pad/sandbox-u= -boot.dtb'), PosixPath('sha1-pad/sandbox-kernel.dtb'), PosixPa...ic/sandbox= -u-boot.dtb'), PosixPath('sha1-basic/sandbox-kernel.dtb'), PosixPath('sha38= 4-basic/sandbox-u-boot.dtb'), ...] > > ------------------------------------ Captured stdout call -------------= ------------------------ > > +make O=3D/tmp/pytest-of-trini/pytest-231/test_clean0 clean > > make[1]: Entering directory '/tmp/pytest-of-trini/pytest-231/test_clean= 0' > > CLEAN cmd > > CLEAN dts/../arch/sandbox/dts > > CLEAN dts > > CLEAN lib > > CLEAN tools > > CLEAN tools/generated > > CLEAN include/bmp_logo.h include/bmp_logo_data.h include/generated/= env.in include/generated/env.txt drivers/video/u_boot_logo.S u-boot u-boot-= dtb.bin u-boot-initial-env u-boot-nodtb.bin u-boot.bin u-boot.cfg u-boot.dt= b u-boot.dtb.gz u-boot.dtb.out u-boot.dts u-boot.lds u-boot.map u-boot.srec= u-boot.sym System.map image.map keep-syms-lto.c lib/efi_loader/helloworld_= efi.S > > make[1]: Leaving directory '/tmp/pytest-of-trini/pytest-231/test_clean0' > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D short test summary info =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > FAILED test/py/tests/test_cleanup_build.py::test_clean - AssertionError= : leftovers: fdt-out.... > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures !!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1 failed, 6 passed in 6.42s =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > That test never passes for me locally, because as you say we add a lot > of files to the build directory and there is no tracking of them such > that 'make clean' could remove them. We could fix that, e.g.: >=20 > 1. Have binman record all its output filenames in a binman.clean file > 2. Have tests always use a 'testfiles' subdir for files they create It sounds like this is showing some bugs in how we use binman since "make clean" should result in a clean tree, and I believe we get a few patches now and again about removing leftover files. > > Fixing that manually with an rm -rf of /tmp/pytest-of-trini and now it's > > stuck. I've rm -rf'd that and git clean -dfx and just repeat that > > failure. I'm hopeful that when I reboot whatever magic is broken will > > be cleaned out. Moving things in to a docker container again, I get: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERRORS =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________ ERROR at setup of test_gpt_read _______= ________________________ > > /home/trini/work/u-boot/u-boot/test/py/tests/test_gpt.py:74: in state_d= isk_image > > ??? > > /home/trini/work/u-boot/u-boot/test/py/tests/test_gpt.py:37: in __init__ > > ??? > > test/py/u_boot_utils.py:279: in __enter__ > > self.module_filename =3D module.__file__ > > E AttributeError: 'NoneType' object has no attribute '__file__' > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D short test summary info =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > ERROR test/py/tests/test_gpt.py::test_gpt_read - AttributeError: 'NoneT= ype' object has no at... > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures !!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 41 passed, 45 skipped, 1 error in 19.29s =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > And then ignoring that one with "-k not gpt": > > test/py/tests/test_android/test_ab.py E > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ERRORS =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > __________________________________ ERROR at setup of test_ab __________= ________________________ > > /home/trini/work/u-boot/u-boot/test/py/tests/test_android/test_ab.py:54= : in ab_disk_image > > ??? > > /home/trini/work/u-boot/u-boot/test/py/tests/test_android/test_ab.py:28= : in __init__ > > ??? > > test/py/u_boot_utils.py:279: in __enter__ > > self.module_filename =3D module.__file__ > > E AttributeError: 'NoneType' object has no attribute '__file__' > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D short test summary info =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > ERROR test/py/tests/test_android/test_ab.py::test_ab - AttributeError: = 'NoneType' object has... > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures !!!!!!!!!!= !!!!!!!!!!!!!!!!!!!!!!!! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 908 passed, 75 skipped, 10 dese= lected, 1 error in 159.17s (0:02:39) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > These two are the same error. It looks like somehow it is unable to > obtain the module with: >=20 > frame =3D inspect.stack()[1] > module =3D inspect.getmodule(frame[0]) >=20 > i.e. module is None >=20 > +Stephen Warren who may know >=20 > What Python version is this? It's the docker container we use for CI, where these tests pass every time they're run normally, whatever is in Ubuntu "Jammy". > > Now, funny things. If I git clean -dfx, I can then get that test to > > pass. So I guess something else isn't cleaning up / is writing to a > > common area? I intentionally build within the source tree, but in a > > subdirectory of that, and indeed a lot of tests write to the source > > directory itself. >=20 > Wow that really is strange. The logic in that class is pretty clever. > Do you see a message like 'Waiting for generated file timestamp to > increase' at any point? >=20 > BTW these problems don't have anything to do with sandbox, which I > think was your original complaint. The more stuff we bring into tests > (Python included) the harder it gets. The original complaint, as I saw it, was that "sandbox pytests don't randomly fail". My point is that sandbox pytests randomly fail all the time. QEMU isn't any worse. I can't say it's better since my local loop is sandbox for sanity then on to hardware. --=20 Tom --2y/BLb0xFBL7vslz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmTC1QAACgkQFHw5/5Y0 tyxtCgv9EvtpkpWqSyp4UhjurDskGOk33Y4qif0qyujquGdLHEFA0+n0AK7oFtSC XQCGRhbMTUOSOOrjOsI7p/aFv11UqqawCvHpXt40GtnxvF+9d1I20GnuhcyRAFM1 dZo5b8NY1A5ccOefHT19zScU3eKN0CN3s6hUMZvk5NvSCyYmc4mZ89mItm6V/lX4 fVAoYdFrLIgqJFPbRXA3508kJWL3wRRvGNn6G6KFsi+IMEZln7EFF9Rxd+PpuK94 9k5bjmvGofBIR5ceF6RhQCP+/taoYKoXzJPZrTKx2mN2XQ26UQ1a4Y3b0F835E9k uLm2G3NpwUlazuUYxlWzIYVcm2IwETilT79KcBajTeGLSBtKtfdwnkauGNqAFMNt G3TH/1fvHP7KJ8OXln8nHnsPdExAPHNFdSg8PhgsmUbdgnZcnq2ORMn5E6uzKzA1 ExfgWpSaqFS9WzbtJj8WOMLJ1zEmm8myzz6WHnOkkujLEMOADyfWChxhQLx5XT2w o4kUgRSH =pJfi -----END PGP SIGNATURE----- --2y/BLb0xFBL7vslz--