Bug#914897: debating the wrong thing

[Ansgar Burchardt]

Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.

There is no "urgent action" required (unlike, say, for the last glibc
update).

If you don't want support for merged-/usr, could you please discuss this
back in 2016 or before that?  Also I feel a general discussion would
probably just be too long-winded and touch too many unrelated issues;
there is not even a terse list of claimed problems.

It is very demotivating to have discussed and implemented something
mostly years ago, for people then to come and complain "let's not do
this at all" years later.

Maybe we should also revisit Multi-Arch now that we know that
`Multi-Arch: foreign` relations as implemented can result in non-booting
systems...

Or really revisit the init system question before people file bugs that
require further urgent action for little gain (it's probably too late in
the release cycle to push in elogind anyway).  There is also the
question if it is still worth to spend maintainer efforts to ship
sysvinit scripts if this means we lose the advantages of declarative
service files (which means far more work than merged-/usr changes)...

We could also open a tech-ctte bug for secure boot before I spend any
more time on it (there are still a few things).  Luckily having this
discussion delays me spending time on the remaining things I wanted to
look at, so at least not more time is wasted.  (Not that I currently
have too much time for Debian anyway, and secure boot is quite a lot of
work for something I don't need...)

Ansgar

Bug#914897: debating the wrong thing

[Adam Borowski]

I see that we're debating the merits of merged-usr vs non-merged-usr, while
expending lots of effort and filing bugs (requiring further urgent action of
unrelated maintainers), for little gain.

In the above, note that the debate vs effort touch different problems:

1. is usrmerge good?
vs
2. how to support both?

I say that 1. is a relatively small issue.  After dropping support for
booting from split /-vs-/usr without initrd, the difference doesn't really
matter.  I'm against pointless moves, but it's not worth an endless debate.
My objection is: repainting the house is a lot of work, paint fumes are bad
for health, the old color was fine and the old paint isn't noticeably flaky.

On the other hand, 2. is madness.  It's taking down load-bearing walls just
so you can have visible sides of both colours.

All the bugs you folks just filed are completely moot if we go all-in,
all-out or step-back-then-in.  So please at least stop filing extra bugs
before the TC decides on the course.

So, let's enumerate possible outcomes:

1. no usrmerge
  1a. no moves at all (no effort needed!)
  1b. moves via some dh_usrmove tool, until /bin is empty
2. supporting both merged-usr and unmerged-usr
3. mandatory usrmerge
  3a. by Bullseye
  3b. by Buster

Unless the TC decides for 2., all this work will be a pure waste of yours
and maintainers' time.

With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in
3a "for now").  With 3b you need some way to make sure existing systems are
converted (also with 3a except for far more time for testing).

And any effort spent doing one of the numbered choices is wasted if we end
up with a choice with a different number.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:
> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current 
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the 
> conversion program would still be in the same exact situation as it is 
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no 
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Adam Borowski]

On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst  wrote:> 
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

That post is too long-winded and touches so many unrelated issues that it's
difficult to respond to it.  Could you please give us a terse list of
claimed benefits?  Without a clear claim, it's too easy to both do or be
accused of doing a straw-man.

By my reading, most of that post either falls into the XY problem or
explains how merged-usr fixes problems caused by merged-usr itself.
That leaves only one concrete claim:
* that merged-usr makes it easier to have a part of the system immutable
  (be it for recovery purposes or for sharing)

My response to that claim is: there's a long list of techniques that can be
used for such an effect without sweeping distribution-wide changes.  Heck,
not even a couple of hours ago I restored from a snapshot multiple times in
order to troubleshoot a broken udev problem.  Here's your "This means you
always have a known-working filesystem to fall back on (if the most recently
updated filesystem doesn't boot, use the other one)".  Or, container
sharing: works fine for me without merged-usr either.  Thus, in order to
make this claim stick, you need to not only list its benefits but also
explain how it's better than other approaches: filesystem-based (btrfs, ZFS,
XFS), vfs-based (various overlays), lvm-based/-like, block-device based,
multiple mounts, etc.  And, many of those can do CoW which is so much better
than immutability.


(Please explain if I understood you wrong.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Simon McVittie]

On Sun, 02 Dec 2018 at 21:04:55 +0100, Marc Haber wrote:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time.

I don't think anyone is proposing that. There's no reason why it would be
preferred over the merged /usr arrangement implemented in both usrmerge
and debhelper --merged-usr, which is the same as is implemented in some
other Linux distributions (e.g. Fedora): /usr is a real directory, and
/bin, /sbin, /lib* are symlinks to the corresponding directories in /usr.

Unifying /usr with / by making /usr a symlink to / is the opposite of
the merged /usr arrangement that is currently implemented. The Debian
hurd-i386 port did try having a /usr -> / symlink a few years ago as a
simplification, but it has all the same transitional issues as merged
/usr, with fewer advantages, which makes it unappealing.

The purpose of merged /usr is to group together all the static files
(/bin, /sbin, /lib* and the current /usr), which are more similar than
they are diferent, into one place that can be a (maybe read-only) mount
point (/usr). If you do the opposite, your root filesystem is still a
mixture of mutable files in /etc and static files in /bin, /sbin, /lib*,
so you haven't gained as much simplification as you would have had with
merged /usr.

(You talk about "default target directories", but there is nothing
so elaborate: debootstrap --merged-usr simply unpacks packages into a
chroot that already contains the symbolic links like /bin -> /usr/bin,
instead of into an empty chroot.)

smcv

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Marco d'Itri]

On Dec 02, Wouter Verhelst  wrote:

> One thing that has not been answered yet in this discussion (and if the
> TC is to make a decision about it, I think it should be) is "why are we
> doing this". That is, what is the problem that usrmerge is meant to
> solve, and how does it attempt to solve it? As far as I know, the reason
> usrmerge exists is so that no files will be installed in /bin anymore;
> but that seems like an XY problem.
https://lists.debian.org/20181121140542.ga31...@espresso.pseudorandom.co.uk

> Also, I would like to ask why the traditional solution in Debian -- make
> a policy change that says no package can ship anything in /bin except
> for a compatibility symlink, and make that rule RC at some point in the
> future -- is not being considered. That seems like a solution that would
> cause far less pain than what we're going through right now.
This is not a solution. For a start it would take many years.
Even ignoring that, it would not bring any improvement over the current 
plan: even if your idea were executed perfectly and quickly then the 
conversion program would still be in the same exact situation as it is 
now: either everything in /bin/, /sbin and /lib (and its own 
subdirectories) was created by the packaging system, and then we already 
know that it can be converted automatically, or it was not, and then we 
know that there are a few cases when the local administrator has to 
decide what to do about things that were installed by himself in the 
past in the wrong place.
So this would make the transition unacceptably slow while providing no 
benefit at all, but it would also cost a huge amount of work to change 
many packages.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Wouter Verhelst]

On Wed, Nov 28, 2018 at 01:49:45PM +, Ian Jackson wrote:
> Control: reassign -1 tech-ctte
> 
> Dear Technical Committee.  I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
> 
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
> 
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
> 
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
> 
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
> 
> So I believe that this change should be immediately reverted in sid
> and buster, so that we do not prejudge the situation by increasing the
> number of buster installs in the field which generate packages which
> are broken on non-merged-/usr systemss.

One thing that has not been answered yet in this discussion (and if the
TC is to make a decision about it, I think it should be) is "why are we
doing this". That is, what is the problem that usrmerge is meant to
solve, and how does it attempt to solve it? As far as I know, the reason
usrmerge exists is so that no files will be installed in /bin anymore;
but that seems like an XY problem.

Also, I would like to ask why the traditional solution in Debian -- make
a policy change that says no package can ship anything in /bin except
for a compatibility symlink, and make that rule RC at some point in the
future -- is not being considered. That seems like a solution that would
cause far less pain than what we're going through right now.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Marc Haber writes:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time. My question was about the distant future, and not the current
> snapshot of things.

If anything then /usr would be the prefix for all packages; nothing
would be installed to /bin, /sbin or /lib.  (And there is no /share or
/local.)

But this is obviously only possible if non-merged-/usr is not supported
at all as that would mean shipping only /usr/bin/sh and no /bin/sh; the
/bin -> /usr/bin symlink would then be required.

Ansgar

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Simon McVittie]

On Sun, 02 Dec 2018 at 19:54:39 +, Simon McVittie wrote:
> When installed on a merged /usr system:

Oops, of course this should have said:

.deb contains -> /bin/grep/usr/bin/perl
/bin/fooexists thanks to /bin symlink   exists thanks to /bin symlink
/usr/bin/foo   physical locationphysical location

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Marc Haber writes:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
>> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
>> > Will binaries move from /usr/bin to /bin? Or will binaries move from
>> > /bin to /usr/bin?
>> 
>> A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
>> /bin/grep will make that binary end up in /usr/bin/grep; but the
>> /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
>> directly or /bin/grep through the symlink.
>
> And where will the binaries and up on an un-usrmerged system with a
> dedicated /usr? in /usr, I hope?

They won't move on a system that doesn't have merged-/usr.  /bin/bash
will stay in /bin/bash.  If you switch to a merged-/usr (for example by
installing usrmerge) then they will be moved to /usr.

Ansgar

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Marc Haber]

On Sun, Dec 02, 2018 at 07:54:39PM +, Simon McVittie wrote:
> I would encourage anyone with questions about the behaviour of merged and
> unmerged /usr systems to try them, either by building one chroot, container
> or VM with merged /usr and one without, or by building a chroot, container
> or VM with unmerged /usr, copying it, and installing usrmerge in the copy.

That would give me an impression about how things are today.

> The answer to your question is that non-/usr-merged systems behave the
> same way they always have: binaries end up wherever the source package
> chooses to put them when it builds the .deb (typically determined by
> where they appear under debian/tmp).

The next debhelper change might choose to give / instead of /usr as a
target directory by default, moving hundreds of megabytes from /usr to /
over time. My question was about the distant future, and not the current
snapshot of things.

And, it has been satisfactorily answered by now.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Simon McVittie]

On Sun, 02 Dec 2018 at 20:16:10 +0100, Marc Haber wrote:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
> > A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
> > /bin/grep will make that binary end up in /usr/bin/grep; but the
> > /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
> > directly or /bin/grep through the symlink.
> 
> And where will the binaries and up on an un-usrmerged system with a
> dedicated /usr? in /usr, I hope?

I would encourage anyone with questions about the behaviour of merged and
unmerged /usr systems to try them, either by building one chroot, container
or VM with merged /usr and one without, or by building a chroot, container
or VM with unmerged /usr, copying it, and installing usrmerge in the copy.

The answer to your question is that non-/usr-merged systems behave the
same way they always have: binaries end up wherever the source package
chooses to put them when it builds the .deb (typically determined by
where they appear under debian/tmp).

To avoid breaking hard-coded paths on existing non-/usr-merged systems,
that has to be where the package has traditionally put them, unless
the package takes special steps to create a compatibility symlink on
non-merged-/usr systems (which I would not recommend[1]).

When installed on an unmerged-/usr system:

.deb contains -> /bin/grep/usr/bin/perl
/bin/foo  physical location   does not exist
/usr/bin/foo   does not exist   physical location

When installed on a merged /usr system:

.deb contains -> /bin/grep/usr/bin/perl
/bin/fooexists thanks to /bin symlink   physical location
/usr/bin/fooexists thanks to /bin symlink   physical location

None of the above depends on whether /usr is a mount point. If /usr is a
mount point, then /bin/grep is physically located on the /usr filesystem
if the system is merged-/usr, or on the root filesystem otherwise.

Replace /bin/grep in the above with any executable that is canonically
in /bin or /sbin (its source package would typically install
something like debian/tmp/bin/grep), and replace /usr/bin/perl with any
executable that is canonically in /usr/bin or /usr/sbin (its source
package would typically install something like debian/tmp/usr/bin/perl).

smcv

[1] 
https://lists.debian.org/msgid-search/20181122205532.ga2...@espresso.pseudorandom.co.uk

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Marc Haber]

On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
> > Will binaries move from /usr/bin to /bin? Or will binaries move from
> > /bin to /usr/bin?
> 
> A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
> /bin/grep will make that binary end up in /usr/bin/grep; but the
> /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
> directly or /bin/grep through the symlink.

And where will the binaries and up on an un-usrmerged system with a
dedicated /usr? in /usr, I hope?

Greetings
Marc



-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Holger Levsen]

On Sat, Dec 01, 2018 at 10:21:50PM +, Simon McVittie wrote:
> gzip, icecc and mailagent were most recently built for buster on
> 2018-11-08, which might be long enough ago that the buster chroot was
> not merged-/usr?

right. I triggered their builds and now they are all shown as unreproducible.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Simon McVittie]

On Sun, 02 Dec 2018 at 21:21:40 +0900, Hideki Yamane wrote:
>   - What is the problem? (broken build for which packages? Just R?)

The problem we're aware of is:

Some packages auto-detect the absolute path to an executable (for example
bash or perl) and hard-code it into their output (for example the #! line
of the bash scripts in quilt). When built on a system with merged /usr,
they can detect and hard-code a path that exists on merged /usr systems
but does not exist on systems with unmerged /usr, such as #!/usr/bin/bash
or #!/bin/perl.  This results in the package working fine on merged-/usr
systems but not on unmerged-/usr systems.

The quilt bug https://bugs.debian.org/913226 is the one that prompted
me to look at this (it caused build failures in a Debian derivative
that I work on, which is in the process of rebasing from stretch to
buster), and is a fairly typical example. The problem case usually
involves an executable that is canonically in /bin, like bash or sed,
being detected in /usr/bin. I've also seen one occurrence of the reverse,
where an executable that is canonically in /usr/bin is found in /bin on
a merged /usr system, although I can't remember which package that was
(it would have to have been re-ordering PATH to look in /bin first).

The same packages would be similarly broken if they were built with
/usr/local/bin in the PATH, on a system where the executable they are
looking for is present in /usr/local/bin. For example, versions of quilt
where #913226 is unfixed could exhibit a similar problem if built on a
system with a /usr/local/bin/bash.

The same things can happen with /usr/sbin and /sbin.

>   - How many packages are affected?

In ,
Ansgar points to 60 packages found to have this failure mode in a rebuild
covering around 80% of the archive, and estimates that there should be
about 80 packages in total affected by this class of bug.

>   - Why it was caused? (just symlink to /bin or /sbin isn't enough
> to deal with it?)

See the quilt bug I linked above, which is a typical example.

On merged /usr systems there is no problem with the "broken" packages,
because the compatibility symlinks /bin -> /usr/bin and /sbin -> /usr/sbin
ensure that paths like /bin/sh and /usr/bin/sh both work equally well.
The problem only occurs when they are *built* on a system *with* merged
/usr, then *used* on a system *without* merged /usr.

>   - Does it cause any failure on users' machine?

Yes, for example see the quilt bug. The failure mode is:

* A developer, D, has a system with merged /usr
* A user, U, has a system without merged /usr
* D builds a package that has this type of bug
  (without using a non-merged-/usr chroot, for example --variant=buildd from
  debootstrap >= 1.0.111)
* The package works for D
* The package doesn't work for U

smcv

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Hideki Yamane]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On Fri, 30 Nov 2018 19:40:45 +0100
"Didier 'OdyX' Raboud"  wrote:
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
> default now, or are you OK letting the TC decide on this subject?

 Hmm, I'm still considering what's the good way...

> Hideki, if I read the debootstrap history correctly, you enabled "merged 
> /usr" 
> by default in debootstrap 1.0.102. 

 Yes, that's right. #839046 was filed in Sep 2016, and uploaded in Jun 2018.

> Given the recent discussion in debian-
> devel@ (starting at [0]) and on #914897, could you (or anyone speaking as 
> with 
> a "debootstrap maintainer" hat on) state if, either of:
> 
> * you would be willing to toggle the "merged /usr" default in debootstrap in a
>   subsequent upload;
> * you maintain that the "merged /usr" default (to yes) is here to stay.

 Well, with a quick look to the thread (I cannot follow all of the email in it,
 tons of emails...), I cannot find the discussion about

  - What is the problem? (broken build for which packages? Just R?)
  - How many packages are affected?
  - Why it was caused? (just symlink to /bin or /sbin isn't enough
to deal with it?)
  - Does it cause any failure on users' machine?

 So, I want to listen above things (not thought or idea), then reply to
 your question. Please quote if someone can do it.


- -- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQZYJUbYxgXxV33EdBBJ4KqpAHFMFAlwDzlUACgkQBBJ4KqpA
HFOnfxAAv8s9EQwntX9SBHALIY+5X1Ma98aMhrzZ2SWDt1txznXRt18z/85oOWqs
FGLrm2QY159qWEG2lpsWhAIr7wQJBPcFH5MRQcn6pDM6pXB1ioaTsW9uhd/AMl+s
mCyvWW0xtJ1ww2EXV2hN5X0K4AAre2rajb0P4p6efeY5V9sbMQ/gZa+L2sJuL1P/
/6fK4Kxe893lVuZ3oxtOhKRkdgi1V1X63kUURofuTSZiVzeGYWAuPdnHBxADs9vK
kk6mpUFkYSeOfg45h2KQzUqeTsX5GTogWIFqEOAJ0KJGDusOiFEPWL/pus+De1E7
cyEX2i6yq3wOOQBov5/eNH2gMs9pDaOqM8hR0tjvya4aAJOa7VyFY2GzMdsEHdQe
Ay7EtzG3RLwuiQ0XrSmIyaDdlJpofCGernNgVu+dnBJb/1U4RHgneVbIELULGUYm
DGFov6FpeUQB6wc/fsaoDWQBiwwNCS2qkJnZJg5nu4ne12NqnERqoq2lIR3ivSe2
1Oi9v/ClKqNSKGLAIoRVvllZhs9W1ppwkZIqtC0mZlN05nw7Wyrj4YoRbJ4r70Rd
rdQzTntchOXbYOmdt2H6yUdpnJJoA46+OxlwykvjrUnDnzgheNMJ0wRh36LcOz50
pjQBQGGVVl/9+Tjw/vSCu+alwLwPY34YFOM8I4fh/V0OHbO4fNE=
=yD0D
-END PGP SIGNATURE-