From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id IMAbIs99RGHL9wAAgWs5BA (envelope-from ) for ; Fri, 17 Sep 2021 13:36:47 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id UPfqHc99RGH7JQAA1q6Kng (envelope-from ) for ; Fri, 17 Sep 2021 11:36:47 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E2E14113AD for ; Fri, 17 Sep 2021 13:36:46 +0200 (CEST) Received: from localhost ([::1]:46352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRCAf-0005oh-Td for larch@yhetil.org; Fri, 17 Sep 2021 07:36:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRC9G-0004Sd-GN for guix-devel@gnu.org; Fri, 17 Sep 2021 07:35:19 -0400 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:35484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRC9D-0003BM-ES for guix-devel@gnu.org; Fri, 17 Sep 2021 07:35:18 -0400 Received: by mail-lf1-x12b.google.com with SMTP id m3so29828787lfu.2 for ; Fri, 17 Sep 2021 04:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop-in.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=/UnKLsOTt3lFA6hbYPTq/N1eao+eUcCkX2YakGpQ0f4=; b=8LzQetxpWm0I7Izr08ir5yJf6P3bSWC8fKa9vFQwuPkEFJP6AWYy+h1PoSM91ufKZD wx6B0WIOp6eC1+BpJZlisOOJRtXKLgbmzWulpQOsEaKDC/W6fAol7LcNKx1/61A5E9jZ Uqhf70d09L9qqOvwbMm5faIzIFGUXxcUBoi9bNANuOKho+CoQplCR3YKcIyTp4YDrNCT 7lbhQtqkXzVfc8wn0vkA3pqwkLTvRC2bHsCYBYMUI+efnYODsqTbZE1Od0SM/9TwLoi7 9nFda+Nkh6HLFbhJDpJeqVrmjnS6b8sSvFRkQjds5dUbIdeMXjOhLjM8STaXiyMnxG65 ilFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=/UnKLsOTt3lFA6hbYPTq/N1eao+eUcCkX2YakGpQ0f4=; b=fyQvfusx0IFzCEqVc3bJFHemiEj1qc5o1uHcHjjjOFwYvITVyN3vXVuXxEvtjHOFbi IZDNVAzlpoDRqxuW4lZiFqBwO+X4peZEift7piQwr5vFhWup5WSQCzX+J7ZSMCKn2l6V 6d94rOskkJ3+QmDPBb9MgWmZHJdFdLfuIJqAG0WLNyAU70yTRR91VJRMnft7o2ylywti PZ4txCeNzHOe1IKh8LrbdpGue05U6k49RmAMW8ec76D9JCue2QSCbMZqUB6MgtZzQqsw xnz5S4TitGXCU9Sdd5b30VdnMxZ2kPdzW3MCm4vWsOA6vrN/tHc7LD2kWI+XIMQnXlv7 UCJg== X-Gm-Message-State: AOAM533SHlW7Z6waRuNSHPGrNEGowj7RVMgG4lKhC17zKJZJ/n/nF5VE dlJeAuLaQuwDcUYuxEkxUYaPoQ== X-Google-Smtp-Source: ABdhPJyEhvYMH2XwmqWbr5I8Qnu4XWa8Ldi7sfl0uoZcq92WMHEwtnKucH9GToEhPVBfCguersCk+Q== X-Received: by 2002:ac2:4bc1:: with SMTP id o1mr7529714lfq.568.1631878512185; Fri, 17 Sep 2021 04:35:12 -0700 (PDT) Received: from localhost ([109.252.93.92]) by smtp.gmail.com with ESMTPSA id y1sm351742ljj.138.2021.09.17.04.35.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 04:35:11 -0700 (PDT) From: Andrew Tropin To: Xinglu Chen , guix-devel@gnu.org Subject: Re: On the naming of System and Home services modules. In-Reply-To: <87h7ejpn4i.fsf@yoctocell.xyz> References: <87zgsei5ta.fsf@trop.in> <87pmtarnrh.fsf@yoctocell.xyz> <87zgscx2px.fsf@trop.in> <87h7ejpn4i.fsf@yoctocell.xyz> Date: Fri, 17 Sep 2021 14:35:07 +0300 Message-ID: <87zgsb8mfo.fsf@trop.in> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=2a00:1450:4864:20::12b; envelope-from=andrew@trop.in; helo=mail-lf1-x12b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sarah Morgensen Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631878607; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=/UnKLsOTt3lFA6hbYPTq/N1eao+eUcCkX2YakGpQ0f4=; b=JBnsPzvSAmXk5BRV8SRrxBIoHhbHz6sBzgkF1hZ9iRRGNRoPvA5+HrFh0a4NPKvoh/glic f32sLUuezCINm5a87AeodAuzH+16V0DPMGvh8vB4l08hkZF3hrXRC9Pi52sdvRSpmznwTs 7jTDdNzQxTT9I/K/DiYSOnS0Gi8ptBTGC3MvbVtlmUN9liveCIFy7SSQf68bnklhAOQedK P0u1m2BkL/Kwwta1af3DsCEfxfTslejhOeDQ9mMvXu8QXfm+VIsFOBT37hC7f/zsBTp//d 4RZ9RCHpzrOMcOuMlDMFaEXkF0ncIZFADqOsMPcWljjI8pLTl/fj34nv8aPlyA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631878607; a=rsa-sha256; cv=none; b=X7o0/Fb0Lf1yhLCdmvZ3GQKwsGDIcUF5u5K0boqsl9nHeK44gicG/PfeKnXUOyIm1CQUBw M7JsnPD8oSfXvnamRqGjvmUfGUnpcy9WnH1YMWiqcvmxWE+llVfWrxfQINT0zy9DHuNlLj Vwvb7rPhyuskB1tGybPdfk8hB51qqSTkYz1Q0FvcCurfJKfDg1tJnsUIRHC0WJHI2KudQ9 avK7HFUb7GE2r3kRR4EhctTfWILW27VNQU4hXEvGLXcMo2B3nXv6zel2JkGI5RSl0gY/hj nvSr5nMs88tzUL4RWKH0w014EIBGfZkfu301SEdFBX1naaFXzCmw7cswI/7uzg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=8LzQetxp; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -3.49 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=8LzQetxp; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: E2E14113AD X-Spam-Score: -3.49 X-Migadu-Scanner: scn0.migadu.com X-TUID: xVD2Is2/rapc --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2021-09-17 11:28, Xinglu Chen wrote: > On Thu, Sep 16 2021, Andrew Tropin wrote: > >>>> * Putting Home Services to ~(gnu services ...)~ >>>> In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested: >>>> >>>>> Regarding module names: what about putting everything in the (gnu >>>>> home =E2=80=A6) name space. For services, I wonder if we could simpl= y use >>>>> (gnu services home), for the essential services, and other (gnu >>>>> services =E2=80=A6) module, but that assumes some code can be shared = between >>>>> System and Home. Thoughts? >>>> >>>> ** Shortcomings >>>> While it's a nice idea, I see some shortcomings here: >>>> >>>> *** Code Reuse >>>> Mcron, Shepherd and a few other fundamental pieces are reused between >>>> Guix Home and Guix System, but it's easily done by exporting a few >>>> symbols from related modules. >>>> >>>> Records even for the same services have slightly different fields and >>>> because of macro nature can't be reused between Home and System >>>> services. In more details I mentioned this problem here: >>>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz= %3E#%3C878s4l8kai.fsf@trop.in%3E >>> >>> Some services might be useful to have in both Guix System and Guix Home; >>> for instance, Guix System currently has a service for configuring >>> Syncthing, and I think it makes sense to also have one for Guix Home, >>> this would mean that people not using Guix System (me :-)) could also >>> have Guix manage Syncthing. With the current approach, we would have to >>> copy and paste quite a bit of code, and if the Syncthing service for >>> Guix System changes, then the one for Guix Home might have to change as >>> well. >>> >> >> We can extract parts, which have to be in sync between home service and >> system service and just use them in both. I don't see how placing home >> service in the same module will decrease the amount of "copy-paste". >> >> If you talk about "shared" fields for configuration records, it's >> probably true, but I don't see any good solution yet. I'm unhappy that >> records are implemented with macros, because it complicates the >> extensibility of the mechanism, wrapping them in more macros doesn't >> make thing better IMO. > > Since we don=E2=80=99t have a way to avoid using macros for records, resi= sting > macros probably won=E2=80=99t really help much. :-) > The fact that we already use them doesn't mean that we need to use more macros, IMO it's a good idea to keep the amount of macros as small as possible. >>> I have thought about a =E2=80=98define-configuration=E2=80=99 macro tha= t would >>> generate one configuration record for Guix system and optionally, >>> one for Guix Home. For example >>> >>> (define-configuration syncthing-configuration >>> ...) >>> >>> would work as it currently does, and >>> >>> (define-configuration syncthing-configuration >>> ... >>> (home-service? #t)) >>> >>> would generate a record and a >>> record. >>> >>> There is the problem of and >>> not having the same fields. To solve >>> this, Each clause could have an =E2=80=98home-service?=E2=80=99 field, = and the code >>> would look like >>> >>> (define-configuration syncthing-configuration >>> (package >>> (package syncthing) >>> "Syncthing package to use.") >>> (arguments >>> (list-of-strings =E2=80=99()) >>> "Command line arguments to pass to the Syncthing package.") >>> (log-flags >>> (integer 0) >>> "Sum of logging flags.") >>> (user >>> (maybe-string 'disabled) >>> "The user as which the Syncthing service is to be run." >>> (home-service? #f)) ; not for Guix Home >>> (group >>> (string "users") >>> "The group as which the Syncthing service is to be run." >>> (home-service? #f)) ; likewise ^^ >>> (home >>> (maybe-string 'disabled) >>> "Common configuration and data directory.") >>> (home-service? #t)) >>> >>> This would mean that would have all the >>> fields, but would have all but the =E2= =80=98user=E2=80=99 >>> and =E2=80=98group=E2=80=99 fields. >>> >>> We could also have a =E2=80=98define-home-configuration=E2=80=99 macro = that would create >>> a record and optionally, a >>> record. Then =E2=80=98home-service?=E2=80=99 woul= d be >>> =E2=80=98system-service?=E2=80=99 instead. >>> >>> Maybe it=E2=80=99s too complicated and not worth it, but it=E2=80=99s j= ust an idea I >>> have had. >>> >> >> define-configuration is already a quite complicated macro, but maybe >> something like that will work, still unhappy with tons of macros for >> implementing records in scheme (: >> >>> >>>> The intersection of home and system services should be very low, so >>>> there is not much benifit here as well. >>> >>> Quite the opposite, I think it would be great if home and system >>> services could integrate more with each other. >> >> The system and home services can't really integrate with each other at >> least because of extension mechanism. >> >>> In NixOS, the NixOS modules and Home Manager modules feel like two >>> very distinct things, and it=E2=80=99s not really easy to share things = between >>> them. >>> >> >> Yes, but with Guix System and Guix Home it's easier to keep them in sync >> and share code between them because they are both a part of the same >> repo. >> >> Going back to intersection: Yes, there are some services that are common >> to Guix Home and System: mcron, shepherd and maybe a few more, but most >> of the `guix system search .` is not relevant for user. >> >> Everything that can be implemented as a home service should implement >> as a home service in most cases. > > Not really sure what you mean by this, but the above proposal would > create a and a record. If something can be both home and system service we can prefer to implement home service, because it can be used on both Guix System and foreign distros. Yes, I got your idea. >> There are two case, where you can bring an argument against it, but >> I'll propose solutions upfront: >> >> - As admin I want to add a service in operating-system, but it's only >> available as a home service. >> >> I think we can do something like that:=20=20 >> >> #+begin_src scheme >> (operating-system >> (services >> (list (service guix-home >> `(("USERNAME1" ,(generate-home-environment >> with-needed-services))))))) >> #+end_src >> >> - I want to start the home service on boot. >> >> Probably, something like linger systemd will be needed here for >> Shepherd, still seems very possible to implement. >> https://www.freedesktop.org/software/systemd/man/loginctl.html#enable-li= nger%20USER%E2%80%A6 > > That would be nice to have. > >> Yes, probably there are cases where we will need to have both system >> and home services, but I expect this number to be very low and >> everything else will fall in one category of services, this is what I >> mean by small intersection. As an exercise try to name 10 services, >> which doesn't belong to only one category. > > Well, there are quite a few that I can think of > > * The ones we have already mentioned: Mcron, Shepherd, and Syncthing. > > * Unattended-upgrade. > > * Rsync/state management. > > * guix-publish: As a normal user, I should be able to run a =E2=80=98guix > publish=E2=80=99 service, to share substitutes with others, without nee= ding > root access. > > * Mail related services: Getmail/Fetchmail/Isync can be used by a normal > user for fetching their mail from some remote server. These programs > can also be used by a server that hosts a Patchwork instance to track > patches sent to a mailing list. I think this is what Christopher=E2=80= =99s > Patchwork instance does. > > > > Dovecot/OpenSMTP/Exim can be used on a mail server, but they can also > be used as a local IMAP server, which something like Gnus can connect > to. > > I have also seen people use Postfix as a Sendmail/Msmtp replacement, > and it would thus make sense to have a Guix Home service for it too. > > * Alsa: There is already an Alsa service for Guix System, but a user may > also want like to configure their ~/.asoundrc file in order to not > pollute the system configuration. > > * WeeChat can be used as an IRC client, and as a relay for other WeeChat > clients to connect to. It would therefore make sense to have WeeChat > running on a server (Guix System), and then connect to it through > WeeChat as a regular user (Guix Home). > > * Shells: Each individual user will most likely configure their shell, > but the sysadmin also might want the configure the system-wide shell > and not just run with the default settings. > > There is also the problem of system service only working on Guix System, > whereas home services will work on foreign distros as well. As someone > who is on a foreign distro, I would like to configure things like Tor > (and Privoxy), Transmission, Ipfs, Bitlbee, and a login manager and a > desktop environment. But right now I have to be on Guix System to > configure to these things. > > That=E2=80=99s just the ones I can think of; other people probably have m= ore > things to add. > I think most of this usecases are solvable by having only home services and linger shepherd. For example an administrator can define a home-environment in operating-system for weechat-relay user, which contains a WeeChat home service, configured as a relay and setup it with `guix system reconfigure`. Any other users can control their own home-environments and configure and install their weechat clients with `guix home` I see the downside that such processes won't be visible in root's herd, but as I already mentioned it doesn't seems to be a big problem and in addition, it is most likely solvable. >>> A while ago, someone on IRC mentioned that it would be nice to have >>> Mcron in Guix System run Mcron jobs that were specified in Guix Home. >>> The rationale is that Guix Home for a user will not activate---run >>> user Shepherd, thus running Mcron---until that user logs in. This >>> means that Bob=E2=80=99s Mcron jobs will only run when Bob is logged in= . The >>> Mcron jobs in specified in Guix System will run regardless if the user >>> that those jobs belong to logs in. But if Bob wants their Mcron jobs >>> to run regardless if he logs in, he needs root access to be able to >>> add jobs to his Guix System config and run =E2=80=98guix system reconfi= gure=E2=80=99. >>> This does mean that the sysadmin has to add =E2=80=98mcron-service-type= =E2=80=99 to >>> the =E2=80=98services=E2=80=99 field of the record, = though. >>> >> >> Covered by linger idea mentioned above. The downside is it won't be >> visible in root's herd cli, but it also fixable either by extending >> shepherd or by using su to run herd from specific user. >> >>>> Utilitary functions like serialization helpers and so on can be >>>> declared in a shared module and reused between System and Home >>>> services. >>>> >>>> Recaping the section: All the necessarry code already reused, the >>>> future home/system services are not expected to share much code, >>>> different utilitary functions can be shared via (gnu services utils) >>>> or (gnu services configuration) modules. >>>> >>>> *** Confusion >>>> I already mentioned that I see a lot of confusion between System and >>>> Shepherd services and I expect some confusion between home and system >>>> services, it will be especially true if we place them in the same >>>> namespace. >>>> >>>> People will be trying to use home services inside operating systems, >>>> #+begin_src scheme >>>> (operating-system >>>> (services >>>> (list (service home-mcron-service-type ...)))) >>>> #+end_src >>>> >>>> and configuration record for system services inside home services. >>>> #+begin_src scheme >>>> (home-environment >>>> ... (service home-mcron-service-type >>>> (mcron-configuration ...))) >>>> #+end_src >>> >>> With the above proposal, the user would use =E2=80=98home-mcron-configu= ration=E2=80=99 >>> for home service, so I don=E2=80=99t think this should be a problem. A= nd as >>> Maxime mentioned, we could have a =E2=80=98validate=E2=80=99 field whic= h would give a >>> friendly error message if the wrong configuration record was given. >>> >>>> ** Summary >>>> Let's keep System and Home services separate for the sake of clarity, >>>> reuse code via shared modules or just exports in (gnu services ...). >>>> >>>> * Putting Home Services to ~(gnu home services ...)~ >>>> Another idea I saw is to move: >>>> ~(gnu home-services)~ -> ~(gnu home services)~ >>>> ~(gnu home-services gnupg)~ -> ~(gnu home services gnupg)~ >>>> ... >>>> >>>> Sounds reasonable, I'll just mention the ideas behind ~home-services~ >>>> name. >>>> >>>> System services have following naming conventions for the public API: >>>> >>>> in ~(gnu services CATEGORY)~ there are ~APP-service-type~, >>>> ~APP-configuration~ and other related symbols. >>>> >>>> Not to be confused, I decided to prefix all service types and >>>> configurations with ~home-~, so the exported symbols looks like: >>>> ~home-APP-service-type~ and ~home-APP-configuration~. >>>> >>>> The same rule applies for module names: We do the same way as system >>>> services do, but with ~home-~ prefix: ~(gnu services CATEGORY)~ for >>>> system, ~(gnu home-services CATEGORY)~ for home. >>>> >>>> All namespaces containing ~system~ now becomes ~home~: ~(gnu system)~ = and >>>> ~(gnu home)~ respectively. >>>> >>>> I find such approach to be consistent and doesn't see to much reasons >>>> to change it. >>>> >>>> However, ~(gnu home services ...)~ also looks cool, but it would be a >>>> little inconsistent with system services, which will have one level of >>>> nestiness less: ~(gnu services)~. >>>> >>>> IMO, ~(gnu home services ...)~ would be a good choice if we use ~(gnu >>>> system services)~ for system services. >>> >>> Yeah, having both (gnu system service) and (gnu home service) could make >>> sense, but since we only have (gnu services), I don=E2=80=99t think it = makes >>> much sense. >>> >> >> Just to clarify, by ..., I meant submodules, so it will be >> (gnu system services version-control) and >> (gnu home services version-control) for example. > > Sorry, I forgot to add ...; I meant (gnu system services ...) and (gnu > home services ...). > >> For now it's just: >> (gnu services version-control) and >> (gnu home-services version-control), which I find okeish. > > I would prefer to just have everything verson-control-related in (gnu > service version-control). Since everything is prefixed with =E2=80=98hom= e-=E2=80=99, it > should make things clear that its used by Guix Home and not Guix System. Ok, got your opinion. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmFEfWsACgkQIgjSCVjB 3rBSwBAAkn1k3Y5uPVgGzxZ2+ZLQSPEoBlUI6MONuPWYLa74oGidc18pSdYHUaRZ +JHQi2fL9eEjdQ4jcM118pMrfs+DDKDZWx3f3ZEv95j5WKg0MkViu+rxe8IwGYlc U1wHqrj8VsM+ybhA220U5uxkq8NdzAa/MXmwnyvW50Y9MAvPu0lFydBJRYsjykeZ W0mu1EhzoZUVtdI9GIP3yNTxFdZCLrvLWbCCfUdqQzMiMvKllz0hpbn4fbgdVFHA tEpRmoJweSeun6n3rohXUYisicO42uYMeKHO2F9QLcWEBtBwvWcywz8OTN+lAcy5 q3cQ4eFB45NKXhxdVbcJ5q7+DnKFl2AZ+r+uY87b0XYtzgbN+hYc3OtXN1zSSoq0 uvoFTBNeaX3tBTH0jiymA3SLyOgW2IepzX8NCHX/0GuqU0OS0rMRqidJCCBd5DFE jh7w5KwqxG/3eq664/1JKWfFc/5QvUNuFHqDgtsadncLmEkyncGqCODXtAKyLWd1 mFX64WlJKd0eE012oucPV4zjurVgs4HnlcZM8ei5EhfkCeGZfpQMPdqf087f6g+C RJO5eQiiUgi9z4C8cgpHeVyjyFA5tjRbs5I0ay5MuGtgocVk3BsmBiz9qHQ8ktb9 QS14PoM176ooXIxsx5hE9OJ6FjiBSdq5ONl4ro1Yy7IOQk63cHg= =4lLl -----END PGP SIGNATURE----- --=-=-=--