Bug#715426: Bug # 715426: Interested in getting this done

2015-12-09 Thread Roderick W. Smith 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've made some more packaging changes on my upstream Sourceforge git
repository. The debian/copyright file should be in good shape now
except for the outstanding question of Secure Boot public keys from
some sources. I've received an e-mail from Steve Langasek stating that
these keys aren't copyrightable, which is why there's no such claim on
the Canonical key; but I'm not sure how to express that in
debian/copyright. In a worst-case scenario, we can drop the Microsoft,
ALT, and Canonical keys from the Debian package.

I've also added some basic debconf support. The package tools should
now ask whether to install rEFInd to the ESP when the package is
installed or reconfigured. (I've tested this and it works for me.) If
somebody else could review this, I'd appreciate it. This could be
improved in the future, but for now I think it's a good start.

Upstream, I've replaced debian/changelog with the version I use on my
PPA. I realize the Debian package will need something else. I need to
review how patches to the debian subdirectory are usually handled for
situations like this.

- -- 
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWaJe/AAoJEFgyRI+V0FjmvT0IAJIKXcvQxVns6KXGqAlrveL6
vYo7Vj61enGQjemZuI7C405GCNfv51bKku78kh/hDrhhWxcnTVik5jIa4BD8xkHY
z0PkFpAMsUaOeDb35+fr8osV9ISJr/i1nlLxdLNdopA8DhigCwF5Kp+6PyzbafN5
QNosxniowXKKnIXy3aiv/ClLHCWKQ89pgKgWjGgSUZE0b7ZU4Dg95pjeXfKtQydy
LdNUQYKngs+11MrLsVIdAnR0ERzXobIVSQz0W2ZH7QhjeTip6HfSj405Z2ebeCYJ
9vw2gdHGwEU44QGIwbVvMIqgJXeOba3UclvVC1Qq0k0McPIb7VgG12GMpNcxd9A=
=jbiK
-END PGP SIGNATURE-

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-30 Thread Tianon Gravi 
On 30 November 2015 at 17:21, Roderick W. Smith  wrote:
> This change should not have been necessary if you were using recent
> files, since I pushed a similar change up to my git repository a while
> ago. This makes me wonder if your problem might have been caused by
> out-of-date files. I've added your change to debian/rules to my own
> git repository. Could you try again?

Ohh, you know what?  I was building against 0.10.0 still, so if the
ability to compile for arm64 was added since the next release, it
obviously won't work there yet. O:)

Sorry for the hassles! :x

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-30 Thread Roderick W. Smith 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/30/2015 05:22 PM, Tianon Gravi wrote:
> On 30 November 2015 at 11:31, Tianon Gravi 
> wrote:
>> Oh nice; since it's working in QEMU, I'm personally all for
>> arch-enablement! :D
> 
> Hmm, I tried compiling on an arm64 porterbox, and got the
> following:

I think I figured out why this failed: I think you were using an
unmodified 0.10.0 tarball. At the moment, my revisions since that
release, including the ARM64 support, are in the rEFInd git repository
on Sourceforge. An attempt to build on ARM64 from 0.10.0 will of
course fail.

I use a script called mkdistrib (which is in the git repository) to
create my tarballs, binary files, etc. You should be able to run it
yourself like this:

./mkdistrib {version} --nosign

It'll create a directory tree called ../snapshots/{version} and put
files there. It will almost certainly error out on you sooner or
later, but not before it's built a source tarball. Alternatively,
here's my latest snapshot:

http://www.rodsbooks.com/refind-src-0.10.0.7.tar.gz

I've made some changes this evening that should clean up many of the
lintian issues. That said, when I ran lintian, I got a much shorter
list than you did. (I tried both from Ubuntu 14.04 and Debian 8.2.)
What options were you passing to it?

Concerning the errata.js file error, that's part of the Creative
Commons license files. I just tossed the whole contents of the
relevant CC Web page into a directory, but I suppose I can replace
that with plain text or something. I think I saw something about a
Debian page with a bunch of archived licenses, so maybe I'll look for
that

- -- 
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWXRYsAAoJEFgyRI+V0Fjm/6EH/Ryhnm9TIFD623Y7j5NXd7/0
NKt75ZUcngV5LDwbKcBWaaGbILv6iOiJxmRvWclg3ZP2DVOOOs0HJDHj0spb3Ibi
ZvCp8igz0dayPkTZ8tu6+TEEmjsXZ8N2dmK7sLXplzAsn1Wx8+SC1tcF2eCfaBlh
bqfcdH0Ad79hljZaBQGKTP7yUcgvSydrZFUNalj53dwG9CkXHCNcdyI9L6Xh9//l
zecLGD8eeRwRuyjejHa2ueWNoII2BlnqbNqRRjgrwbHqa/oeO4XivhclZoGgPHyY
KvKJh8tdAfa6RrV9Tf2baC3niZOHZjMr/DmcXqODlbC2xv2W3tVA32cIox5WPF4=
=gV9B
-END PGP SIGNATURE-

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-30 Thread Roderick W. Smith 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/30/2015 05:22 PM, Tianon Gravi wrote:
> On 30 November 2015 at 11:31, Tianon Gravi 
> wrote:
>> Oh nice; since it's working in QEMU, I'm personally all for
>> arch-enablement! :D
> 
> Hmm, I tried compiling on an arm64 porterbox, and got the
> following:

That's VERY strange

> make[3]: Entering directory '/home/tianon/refind/libeg' 
> /usr/bin/gcc -I. -I./../include -I/usr/include/efi 
> -I/usr/include/efi/aarch64 -I/usr/include/efi/protocol
> -I../include -I../refind -I../libeg -DCONFIG_aarch64
> -D__MAKEWITH_GNUEFI   -O2 -fno-strict-aliasing -fno-stack-protector
> -fpic -fshort-wchar -mno-red-zone -Wall -c screen.c -o screen.o 
> gcc: error: unrecognized command line option '-mno-red-zone' 
> ../Make.common:89: recipe for target 'screen.o' failed

What's weird about this is that there are signs of both ARM64 and
x86-64 compilation -- "-I/usr/include/efi/aarch64" is obviously ARM64,
but "-mno-red-zone" should be added as an option only on x86-64 systems.

I tried building a Debian package myself in my QEMU environment and
had no problems with it. I tried pushing it up to my testing PPA
(https://launchpad.net/~rodsmith/+archive/ubuntu/testing/+packages),
but it didn't even try to build for ARM64, since that ability is not
enabled by default. I've asked that it be enabled, but I'm not sure
how long that will take.

> The only changes I've applied over what's in master right now are:
> 
> diff --git a/debian/control b/debian/control index 3c130f3..7ca3fa4
> 100644 --- a/debian/control +++ b/debian/control @@ -10,7 +10,7 @@
> Vcs-Browser: 
> https://anonscm.debian.org/cgit/collab-maint/refind.git Vcs-Git:
> git://anonscm.debian.org/collab-maint/refind.git
> 
> Package: refind -Architecture: amd64 i386 +Architecture: amd64
> arm64 i386

This change should not have been necessary if you were using recent
files, since I pushed a similar change up to my git repository a while
ago. This makes me wonder if your problem might have been caused by
out-of-date files. I've added your change to debian/rules to my own
git repository. Could you try again?

> So maybe we should hold off on that bit until we're sure it's
> working more generically? (unless there's something obvious I
> missed O:) )

I'm willing to hold off on ARM64 builds if you continue to have
problems. It's not like the world's knocking down my door for ARM64
versions of rEFInd. ;-)

- -- 
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWXPYgAAoJEFgyRI+V0FjmzuMH+gK/EVKEjAWiMm3oeHck5/7F
t3knRDmFPjJDCPErL6t4Co2F36O0/yj8B+NBZ4aRHl/y3z53bt73DCR5iLRnQvWb
XsnLmWsAu6fWXdd+Gk5dcIXs7YaWjtF26uWniQkyseki7qhc6WocjAIB0s9bwpEW
h5lhJKnL7HstVwl+j+kLQTyt3O0N56JittyU+xIokPOS8F7Zsa8AEJ5Y1A/m9xEq
PBxYTbeUQNvBrS4gh4/wGaH1PG2xmZPe3qQvp0um0xxG1aEgNgcouZI4GBHKVDYj
8h5ngCALsiAPAxFXfRk+6ooY7qkSLdN/djM2JJSogbOtVp16qWGGSMNdwvKr98Y=
=/D6t
-END PGP SIGNATURE-

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-30 Thread Tianon Gravi 
On 30 November 2015 at 11:31, Tianon Gravi  wrote:
> Oh nice; since it's working in QEMU, I'm personally all for arch-enablement! 
> :D

Hmm, I tried compiling on an arm64 porterbox, and got the following:

make[3]: Entering directory '/home/tianon/refind/libeg'
/usr/bin/gcc -I. -I./../include -I/usr/include/efi
-I/usr/include/efi/aarch64 -I/usr/include/efi/protocol -I../include
-I../refind -I../libeg -DCONFIG_aarch64 -D__MAKEWITH_GNUEFI   -O2
-fno-strict-aliasing -fno-stack-protector -fpic -fshort-wchar
-mno-red-zone -Wall -c screen.c -o screen.o
gcc: error: unrecognized command line option '-mno-red-zone'
../Make.common:89: recipe for target 'screen.o' failed

The only changes I've applied over what's in master right now are:

diff --git a/debian/control b/debian/control
index 3c130f3..7ca3fa4 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/refind.git
 Vcs-Git: git://anonscm.debian.org/collab-maint/refind.git

 Package: refind
-Architecture: amd64 i386
+Architecture: amd64 arm64 i386
 Depends: efibootmgr, openssl, parted, ${misc:Depends}
 Description: boot manager for EFI-based computers
  A graphical boot manager for EFI- and UEFI-based computers, such as all
diff --git a/debian/rules b/debian/rules
index 6f9c7f2..e18c5c3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,10 +9,14 @@ else
 ifeq (i386, $(DEB_HOST_ARCH_CPU))
  EFI_ARCH := ia32
 else
+ifeq (arm64, $(DEB_HOST_ARCH_CPU))
+ EFI_ARCH := aa64
+else
  $(warning EFI architecture for $(DEB_HOST_ARCH_CPU) is unknown)
  EFI_ARCH := $(DEB_HOST_ARCH_CPU)
 endif
 endif
+endif

 %:
  dh $@

So maybe we should hold off on that bit until we're sure it's working
more generically? (unless there's something obvious I missed O:) )

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-30 Thread Tianon Gravi 
On 30 November 2015 at 19:38, Roderick W. Smith  wrote:
> I think I figured out why this failed: I think you were using an
> unmodified 0.10.0 tarball. At the moment, my revisions since that
> release, including the ARM64 support, are in the rEFInd git repository
> on Sourceforge. An attempt to build on ARM64 from 0.10.0 will of
> course fail.

Yeah, that's definitely the issue. :)

> I use a script called mkdistrib (which is in the git repository) to
> create my tarballs, binary files, etc. You should be able to run it
> yourself like this:
>
> ./mkdistrib {version} --nosign
>
> It'll create a directory tree called ../snapshots/{version} and put
> files there. It will almost certainly error out on you sooner or
> later, but not before it's built a source tarball. Alternatively,
> here's my latest snapshot:
>
> http://www.rodsbooks.com/refind-src-0.10.0.7.tar.gz
>
> I've made some changes this evening that should clean up many of the
> lintian issues. That said, when I ran lintian, I got a much shorter
> list than you did. (I tried both from Ubuntu 14.04 and Debian 8.2.)
> What options were you passing to it?

Ah, I'll do a re-sync of debian/, try building a newer upstream
snapshot, and see where that lands us! :D

I use lintian from sid, not from a release, since that's the only way
I know of to make sure I've got the latest updates.  In this case, I
run ran "lintian refind_*.changes", not even the usual
"-EvIL+pedantic" I usually like perusing (but which normally has quite
a few more false positives).

> Concerning the errata.js file error, that's part of the Creative
> Commons license files. I just tossed the whole contents of the
> relevant CC Web page into a directory, but I suppose I can replace
> that with plain text or something. I think I saw something about a
> Debian page with a bunch of archived licenses, so maybe I'll look for
> that

Yeah, if you're willing to remove that file from upstream's source
tarballs entirely, that's definitely our best solution!  I think
https://creativecommons.org/licenses/by-sa/3.0/legalcode.txt is a
plain-text version of the HTML currently contained in the source. :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-29 Thread Rod Smith 
On 11/25/2015 01:17 PM, Tianon Gravi wrote:
> On 25 November 2015 at 09:37, Roderick W. Smith  
> wrote:
>> Thanks! FWIW, I made some changes to 0.10.0 to help get the packaging
>> ready, although I realize it's not quite there yet. I need to do
>> another pass through the files to get all the copyright details
>> properly documented and create some patches to get the post-install
>> script doing the right stuff (that is, not installing to the ESP
>> automatically).
> 
> Nice!  If you've got an Alioth account and commit on collab-maint,
> feel free to commit directly to the WIP repo I set up (and if not, you
> should definitely register for a -guest account :D;
> https://alioth.debian.org/account/register.php).

I registered for an account (srs5694-guest).

> I started converting the d/copyright file you've started over to the
> DEP 5 format (http://dep.debian.net/deps/dep5/), but it still needs a
> bit of work for sure (and I didn't check yet whether it already has a
> section for debian/*, just copied the entires you'd already put in
> with a TODO comment at the bottom for more work we need to do for full
> format compliance).

Because your changes all seemed useful to my own Ubuntu PPA (except
maybe for debian/changelog), in the interests of simplicity I've pulled
them all in to the main rEFInd repository on Sourceforge. I've also done
another round of documenting licenses, so debian/copyright on my
Sourceforge git repository is now expanded. There's more yet to be done,
but I'm leaving that for another day.

Incidentally, this weekend I ended up spending a lot of time getting
rEFInd to compile and run on ARM64. It seems to work fine for me under
QEMU, but it's still not very well-tested on that platform. I've added
arm64 to the supported platforms in the Debian packaging, but I'm
willing to nix that in the short term if you think that would be safer.

>> I was actually looking at the GRUB 2 packaging the other day, but it's
>> VERY complex!
> 
> Perhaps we punt on the postinst for now and just document in a
> README.Debian or something how to install it?  Having "refind-install"
> (and all the proper files) available is leaps and bounds ahead of
> where we're at now in the archive, so IMO just that would be a great
> start. :)  (With the plus side being that we could upload that as soon
> as we get the d/copyright finished.)

I took a brief look at the ELILO and gummiboot packaging today. The
former has a postinst script that may be a useful model, although I've
not yet studied it in detail. It sources /usr/share/debconf/confmodule
and then acts or doesn't depending on debconf settings. I'm only a
beginner when it comes to debconf, so I'll have to study this to figure
out what the ELILO package is doing and whether that approach can be
applied to rEFInd.

I've collected enough changes in the main rEFInd package since 0.10.0
that I hope to push out a 0.10.1 version soon -- probably in a week or
two. My intent is to get the debian/copyright and other major packaging
files in order by that time so as to smooth the way to getting 0.10.1
included in the Debian repos, assuming no major unforseen hangup.

-- 
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-25 Thread Tianon Gravi 
Control: owner -1 tia...@debian.org

On Thu, 17 Sep 2015 16:26:35 -0400 "Roderick W. Smith"
 wrote:
> I'm rEFInd's upstream maintainer and a Canonical employee, and I'm
> interested in getting this packaged and the bug cleared.
>
> I've done some Debian packaging, and in fact I've created an Ubuntu
> PPA for rEFInd (see
> https://launchpad.net/~rodsmith/+archive/ubuntu/refind), so much of
> the technical work is already done. (I realize there will need to be
> some changes for a package in Debian's main archive, though, such as a
> change so that the installation script does not run automatically when
> the package is installed.)
>
> I'm less familiar with the procedures for adding a package to the
> Debian archives, though. I'm reading up on this, but if somebody would
> be willing to help guide me through the process, I'd appreciate
> getting some help.

Hey Roderick!  I'm interested in getting this package into the archive
too, so I'd be glad to help out and be the Debian maintainer,
especially with such an obviously engaged upstream. :)

I've created a repo in collab-maint (will show up at
https://anonscm.debian.org/cgit/collab-maint/refind.git eventually),
and I'm currently working on getting your packaging ported over so I
can evaluate what needs to change for Debian.  It's probably worth
taking a look at how "grub" and "lilo" handle the install stuff so we
can mimic.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-25 Thread Roderick W. Smith 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2015 12:21 PM, Tianon Gravi wrote:
> Control: owner -1 tia...@debian.org
> 
> On Thu, 17 Sep 2015 16:26:35 -0400 "Roderick W. Smith" 
>  wrote:
>> I'm rEFInd's upstream maintainer and a Canonical employee, and
>> I'm interested in getting this packaged and the bug cleared.
> 
> Hey Roderick!  I'm interested in getting this package into the
> archive too, so I'd be glad to help out and be the Debian
> maintainer, especially with such an obviously engaged upstream. :)
> 
> I've created a repo in collab-maint (will show up at 
> https://anonscm.debian.org/cgit/collab-maint/refind.git
> eventually), and I'm currently working on getting your packaging
> ported over so I can evaluate what needs to change for Debian.
> It's probably worth taking a look at how "grub" and "lilo" handle
> the install stuff so we can mimic.

Thanks! FWIW, I made some changes to 0.10.0 to help get the packaging
ready, although I realize it's not quite there yet. I need to do
another pass through the files to get all the copyright details
properly documented and create some patches to get the post-install
script doing the right stuff (that is, not installing to the ESP
automatically).

I was actually looking at the GRUB 2 packaging the other day, but it's
VERY complex! I haven't looked at LILO, ELILO, SYSLINUX, or anything
else yet. One concern/question I have is how the OS knows which, if
any, boot loader should be installed. I'm not sure if this is an issue
with Debian, but Ubuntu has a habit of re-installing GRUB if it's
removed, which of course is annoying if you're using something else.
If there's some approved Debian way of recording what boot loader(s)
are in use, we should tie into that.

I was planning on doing more work on this packaging issue this
weekend, which is a long one in the US because of Thanksgiving.

- -- 
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWVfHzAAoJEFgyRI+V0FjmTBwH/jJtL1r+5+Ye5Pg83o7P7amZ
/g95pwKuAv04IQX5I3reb2B/qxPWPRlY/fKeaDfOZchav/v04n6Fk1iuMc9iknaI
17XGhQx6s94wlKLEWQCoX0zlqJ3teUSaYdN+nzZd1Nph94HIqjtLEOQ9FK4qGeim
dLuVA/zKg/Jp6b0O8qpjXBaGrgOjvLLE1A07QEhUeO2SpWokva6QPUsTeZu/j8HG
LREq6jLoC2QEspEqGa+PgYv/yjP94d/zuI/bE7s1BGXvPSeOidbCcoxBvf6DLnp5
Tu/EhheE3DsZzmXB9cff1vLcMHuRSYc5iQ0oh/7rLms3HBjWbJFcTexZeEvXnrA=
=EIz6
-END PGP SIGNATURE-

Bug#715426: Bug # 715426: Interested in getting this done

2015-11-25 Thread Tianon Gravi 
On 25 November 2015 at 09:37, Roderick W. Smith  wrote:
> Thanks! FWIW, I made some changes to 0.10.0 to help get the packaging
> ready, although I realize it's not quite there yet. I need to do
> another pass through the files to get all the copyright details
> properly documented and create some patches to get the post-install
> script doing the right stuff (that is, not installing to the ESP
> automatically).

Nice!  If you've got an Alioth account and commit on collab-maint,
feel free to commit directly to the WIP repo I set up (and if not, you
should definitely register for a -guest account :D;
https://alioth.debian.org/account/register.php).

I started converting the d/copyright file you've started over to the
DEP 5 format (http://dep.debian.net/deps/dep5/), but it still needs a
bit of work for sure (and I didn't check yet whether it already has a
section for debian/*, just copied the entires you'd already put in
with a TODO comment at the bottom for more work we need to do for full
format compliance).

> I was actually looking at the GRUB 2 packaging the other day, but it's
> VERY complex! I haven't looked at LILO, ELILO, SYSLINUX, or anything
> else yet. One concern/question I have is how the OS knows which, if
> any, boot loader should be installed. I'm not sure if this is an issue
> with Debian, but Ubuntu has a habit of re-installing GRUB if it's
> removed, which of course is annoying if you're using something else.
> If there's some approved Debian way of recording what boot loader(s)
> are in use, we should tie into that.
>
> I was planning on doing more work on this packaging issue this
> weekend, which is a long one in the US because of Thanksgiving.

Perhaps we punt on the postinst for now and just document in a
README.Debian or something how to install it?  Having "refind-install"
(and all the proper files) available is leaps and bounds ahead of
where we're at now in the archive, so IMO just that would be a great
start. :)  (With the plus side being that we could upload that as soon
as we get the d/copyright finished.)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#715426: Bug # 715426: Interested in getting this done

2015-09-17 Thread Roderick W. Smith 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'm rEFInd's upstream maintainer and a Canonical employee, and I'm
interested in getting this packaged and the bug cleared.

I've done some Debian packaging, and in fact I've created an Ubuntu
PPA for rEFInd (see
https://launchpad.net/~rodsmith/+archive/ubuntu/refind), so much of
the technical work is already done. (I realize there will need to be
some changes for a package in Debian's main archive, though, such as a
change so that the installation script does not run automatically when
the package is installed.)

I'm less familiar with the procedures for adding a package to the
Debian archives, though. I'm reading up on this, but if somebody would
be willing to help guide me through the process, I'd appreciate
getting some help.

Thanks!

- -- 
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV+yH7AAoJEFgyRI+V0FjmyVMH/A94tcfjwi2SJfoNcF2wsYNh
1Y0aoOuJXwQqJ76WITpIaJHb7dzSPFg/63LlI2c3wXNMFVg/mlJWwux3SkM+Tc1v
ibudZ/nO3C4iHw/+roMp/VBFXqjgaAUOiQwQqFhH0guQTZjECNUTJbwMK3/ileqh
qoi+5W9ih+ETg0I3GvCVcP8v+/36UcSosJsgzT10x2QRHe4S2iGxGBMui5QAJaJ+
TXdIuARG7d2nZ12cZ1OvtBDe4kAdWfpDaQZhrX7A4RLIXWl/9TeYvTy0afu2+fva
b7gRht3TdjDXUU1yV+rev9BYP3r1jR4pLDCymAnb4tNeKlCTYv8UTsR7yh9CzYY=
=1fEL
-END PGP SIGNATURE-