renaming configure.in to configure.ac
It was mentioned elsewhere in passing that a new Autoconf release might
be coming. That one will warn about the old naming "configure.in" and
request "configure.ac". So we might want to rename that sometime.
Before we get into the specifics, I suggest that all interested parties
check whether buildfarm scripts, packaging scripts, etc. need to be
adjusted for the newer name.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 7/15/20 9:14 AM, Peter Eisentraut wrote:
It was mentioned elsewhere in passing that a new Autoconf release
might be coming. That one will warn about the old naming
"configure.in" and request "configure.ac". So we might want to rename
that sometime. Before we get into the specifics, I suggest that all
interested parties check whether buildfarm scripts, packaging scripts,
etc. need to be adjusted for the newer name.
The buildfarm does not use autoconf at all, so it won't care less what
the file is called.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
It was mentioned elsewhere in passing that a new Autoconf release might
be coming. That one will warn about the old naming "configure.in" and
request "configure.ac". So we might want to rename that sometime.
Before we get into the specifics, I suggest that all interested parties
check whether buildfarm scripts, packaging scripts, etc. need to be
adjusted for the newer name.
Along the same line, I read at [1]https://lists.gnu.org/archive/html/autoconf/2020-07/msg00006.html
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:
Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.
regards, tom lane
[1]: https://lists.gnu.org/archive/html/autoconf/2020-07/msg00006.html
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
It was mentioned elsewhere in passing that a new Autoconf release might
be coming. That one will warn about the old naming "configure.in" and
request "configure.ac". So we might want to rename that sometime.
Before we get into the specifics, I suggest that all interested parties
check whether buildfarm scripts, packaging scripts, etc. need to be
adjusted for the newer name.Along the same line, I read at [1]
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.
Sounds good. A cheap option would be to regenerate with 2.70, push that on a
Friday night to see what the buildfarm thinks, and revert it on Sunday night.
Noah Misch <noah@leadboat.com> writes:
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
It was mentioned elsewhere in passing that a new Autoconf release might
be coming. That one will warn about the old naming "configure.in" and
request "configure.ac". So we might want to rename that sometime.
Before we get into the specifics, I suggest that all interested parties
check whether buildfarm scripts, packaging scripts, etc. need to be
adjusted for the newer name.Along the same line, I read at [1]
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.Sounds good. A cheap option would be to regenerate with 2.70, push that on a
Friday night to see what the buildfarm thinks, and revert it on Sunday night.
Instead of doing this on the master branch, would it be worth defining a
namespace for branches that the buildfarm tests in addition to master
and REL_*_STABLE?
In the Perl world we have this in the form of smoke-me/* branches, and
it's invaluable to be able to test things across many platforms without
breaking blead (our name for the main development branch).
- ilmari
--
- Twitter seems more influential [than blogs] in the 'gets reported in
the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
to a mainstream media article. - Calle Dybedahl
Noah Misch <noah@leadboat.com> writes:
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.
Sounds good. A cheap option would be to regenerate with 2.70, push that on a
Friday night to see what the buildfarm thinks, and revert it on Sunday night.
We'd have to rename configure.in as per $subject; but AFAIK that works
with extant autoconf, so we could just do it and leave it that way,
figuring that it'll have to happen eventually.
More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
planning to revert only if things break. The cost to that is that
committers who want to commit configure.ac changes would have to install
2.69b. But they'd be having to install 2.70 whenever we move to that,
anyway, so I'm not sure that's a big cost.
regards, tom lane
On 7/16/20 11:24 AM, Tom Lane wrote:
Noah Misch <noah@leadboat.com> writes:
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.Sounds good. A cheap option would be to regenerate with 2.70, push that on a
Friday night to see what the buildfarm thinks, and revert it on Sunday night.We'd have to rename configure.in as per $subject; but AFAIK that works
with extant autoconf, so we could just do it and leave it that way,
figuring that it'll have to happen eventually.
Yeah, let's just do that forthwith.
More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
planning to revert only if things break. The cost to that is that
committers who want to commit configure.ac changes would have to install
2.69b. But they'd be having to install 2.70 whenever we move to that,
anyway, so I'm not sure that's a big cost.
I don't think it's a big cost. IIRC for quite some years we had to keep
2 or 3 versions of autoconf to cover all the live branches.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 7/16/20 11:24 AM, Tom Lane wrote:
More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
planning to revert only if things break. The cost to that is that
committers who want to commit configure.ac changes would have to install
2.69b. But they'd be having to install 2.70 whenever we move to that,
anyway, so I'm not sure that's a big cost.
I don't think it's a big cost. IIRC for quite some years we had to keep
2 or 3 versions of autoconf to cover all the live branches.
Yeah, everyone who's had a commit bit for more than a few years
has a workflow that allows for using different autoconf versions
for different branches. And if the autoconf crew get their act
back together and start making regular releases again, that will
become the norm for us again too --- so the newer committers had
better get set up to handle this if they aren't already.
regards, tom lane
Hi,
On July 16, 2020 8:24:15 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Noah Misch <noah@leadboat.com> writes:
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
More ambitiously, we could just adopt 2.69b in HEAD and see what
happens,
planning to revert only if things break. The cost to that is that
committers who want to commit configure.ac changes would have to
install
2.69b. But they'd be having to install 2.70 whenever we move to that,
anyway, so I'm not sure that's a big cost.
I think it'd be a good plan to adopt the beta on master.
We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There aren't that many changes to configure it total, and particularly not in the back branches. So I think it'd be ok overhead wise.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Andres Freund <andres@anarazel.de> writes:
I think it'd be a good plan to adopt the beta on master.
We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There aren't that many changes to configure it total, and particularly not in the back branches. So I think it'd be ok overhead wise.
Yeah. Because we'd want to rip out those hacks, it's not quite as simple
as "regenerate configure with this other autoconf version"; somebody will
have to do some preliminary investigation and produce a patch for the
autoconf input files. Peter, were you intending to do that?
regards, tom lane
On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Manns�ker wrote:
Noah Misch <noah@leadboat.com> writes:
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
Along the same line, I read at [1]
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:Maybe we should do some pro-active testing, rather than just waiting for
2.70 to get dropped on us? God knows how long it will be until 2.71.Sounds good. A cheap option would be to regenerate with 2.70, push that on a
Friday night to see what the buildfarm thinks, and revert it on Sunday night.Instead of doing this on the master branch, would it be worth defining a
namespace for branches that the buildfarm tests in addition to master
and REL_*_STABLE?In the Perl world we have this in the form of smoke-me/* branches, and
it's invaluable to be able to test things across many platforms without
breaking blead (our name for the main development branch).
Potentially. What advantages and disadvantages has Perl experienced?
(Given the support downthread for just changing master indefinitely, which is
fine with me, it's more likely this particular change won't use such a branch.
There have been and will be other changes that may benefit.)
On 2020-07-16 18:17, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
I think it'd be a good plan to adopt the beta on master.
We already have parts of it backpacked, there have been things we couldn't easily do because of bugs in 2.69. There aren't that many changes to configure it total, and particularly not in the back branches. So I think it'd be ok overhead wise.
Yeah. Because we'd want to rip out those hacks, it's not quite as simple
as "regenerate configure with this other autoconf version"; somebody will
have to do some preliminary investigation and produce a patch for the
autoconf input files. Peter, were you intending to do that?
Okay, let's take a look. Attached is a patch series.
v1-0001-Rename-configure.in-to-configure.ac.patch
This is unsurprising.
v1-0002-Update-to-Autoconf-2.69b.patch.bz2
This runs auto(re)conf 2.69b and cleans up a minimal amount of obsoleted
stuff.
The bulk of the changes in the produced configure are from the change
from echo to printf. Not much else that's too interesting. I think a
lot of the compatibility/testing advisories relate to the way you write
your configure.ac, not so much to the produced shell code.
v1-0003-Remove-check_decls.m4-obsoleted-by-Autoconf-updat.patch
This is something we had backported and is now no longer necessary.
Note that there are no significant changes in the produced configure,
which is good.
v1-0004-configure.ac-Remove-_DARWIN_USE_64_BIT_INODE-hack.patch
This is also something that has been obsoleted.
I'm not immediately aware of anything else that can be removed, cleaned,
or simplified.
One thing that's annoying is that the release notes claim that configure
should now be faster, and some of the changes they have made should
support that, but my (limited) testing doesn't bear that out. Most
notably, the newly arisen test
checking for g++ option to enable C++11 features... none needed
takes approximately 10 seconds(!) on my machine (for one loop, since
"none needed"; good luck if you need more than none).
This clearly depends on a lot of specifics of the environment, so some
more testing would be useful. This is perhaps something we can
construct some useful feedback for.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
v1-0001-Rename-configure.in-to-configure.ac.patchtext/plain; charset=UTF-8; name=v1-0001-Rename-configure.in-to-configure.ac.patch; x-mac-creator=0; x-mac-type=0Download
From f13940654f84b8fd0954408c69d5f64134fa5045 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Fri, 17 Jul 2020 10:26:27 +0200
Subject: [PATCH v1 1/4] Rename configure.in to configure.ac
---
config/general.m4 | 2 +-
configure.in => configure.ac | 4 ++--
src/backend/catalog/Makefile | 4 ++--
src/include/pg_config.h.in | 2 +-
src/tools/msvc/Solution.pm | 10 +++++-----
src/tools/version_stamp.pl | 12 ++++++------
6 files changed, 17 insertions(+), 17 deletions(-)
rename configure.in => configure.ac (99%)
diff --git a/config/general.m4 b/config/general.m4
index 95d65ceb09..140b9737bf 100644
--- a/config/general.m4
+++ b/config/general.m4
@@ -8,7 +8,7 @@
# argument (other than "yes/no"), etc.
#
# The point of this implementation is to reduce code size and
-# redundancy in configure.in and to improve robustness and consistency
+# redundancy in configure.ac and to improve robustness and consistency
# in the option evaluation code.
diff --git a/configure.in b/configure.ac
similarity index 99%
rename from configure.in
rename to configure.ac
index 2e05ce2e4d..3f49467ccd 100644
--- a/configure.in
+++ b/configure.ac
@@ -1,5 +1,5 @@
dnl Process this file with autoconf to produce a configure script.
-dnl configure.in
+dnl configure.ac
dnl
dnl Developers, please strive to achieve this order:
dnl
@@ -21,7 +21,7 @@ AC_INIT([PostgreSQL], [14devel], [pgsql-bugs@lists.postgresql.org], [], [https:/
m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.69], [], [m4_fatal([Autoconf version 2.69 is required.
Untested combinations of 'autoconf' and PostgreSQL versions are not
-recommended. You can remove the check from 'configure.in' but it is then
+recommended. You can remove the check from 'configure.ac' but it is then
your responsibility whether the result works or not.])])
AC_COPYRIGHT([Copyright (c) 1996-2020, PostgreSQL Global Development Group])
AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c])
diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile
index 9499bb33e5..93cf6d4368 100644
--- a/src/backend/catalog/Makefile
+++ b/src/backend/catalog/Makefile
@@ -103,10 +103,10 @@ generated-header-symlinks: $(top_builddir)/src/include/catalog/header-stamp
# won't update them if they didn't change (to avoid unnecessary recompiles).
# Technically, this should depend on Makefile.global which supplies
# $(MAJORVERSION); but then genbki.pl would need to be re-run after every
-# configure run, even in distribution tarballs. So depending on configure.in
+# configure run, even in distribution tarballs. So depending on configure.ac
# instead is cheating a bit, but it will achieve the goal of updating the
# version number when it changes.
-bki-stamp: genbki.pl Catalog.pm $(POSTGRES_BKI_SRCS) $(POSTGRES_BKI_DATA) $(top_srcdir)/configure.in
+bki-stamp: genbki.pl Catalog.pm $(POSTGRES_BKI_SRCS) $(POSTGRES_BKI_DATA) $(top_srcdir)/configure.ac
$(PERL) $< --include-path=$(top_srcdir)/src/include/ \
--set-version=$(MAJORVERSION) $(POSTGRES_BKI_SRCS)
touch $@
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index c199cd46d2..11567064b3 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -1,4 +1,4 @@
-/* src/include/pg_config.h.in. Generated from configure.in by autoheader. */
+/* src/include/pg_config.h.in. Generated from configure.ac by autoheader. */
/* Define to the type of arg 1 of 'accept' */
#undef ACCEPT_TYPE_ARG1
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index a13ca6e02e..4dbfc1f3ec 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -153,9 +153,9 @@ sub GenerateFiles
my $package_url;
my ($majorver, $minorver);
- # Parse configure.in to get version numbers
- open(my $c, '<', "configure.in")
- || confess("Could not open configure.in for reading\n");
+ # Parse configure.ac to get version numbers
+ open(my $c, '<', "configure.ac")
+ || confess("Could not open configure.ac for reading\n");
while (<$c>)
{
if (/^AC_INIT\(\[([^\]]+)\], \[([^\]]+)\], \[([^\]]+)\], \[([^\]]*)\], \[([^\]]+)\]/
@@ -178,7 +178,7 @@ sub GenerateFiles
}
}
close($c);
- confess "Unable to parse configure.in for all variables!"
+ confess "Unable to parse configure.ac for all variables!"
unless $ac_init_found;
if (IsNewer("src/include/pg_config_os.h", "src/include/port/win32.h"))
@@ -826,7 +826,7 @@ EOF
# Read lines from input file and substitute symbols using the same
# logic that config.status uses. There should be one call of this for
-# each AC_CONFIG_HEADERS call in configure.in.
+# each AC_CONFIG_HEADERS call in configure.ac.
#
# If the "required" argument is true, we also keep track which of our
# defines have been found and error out if any are left unused at the
diff --git a/src/tools/version_stamp.pl b/src/tools/version_stamp.pl
index 3595587622..36b18d514c 100755
--- a/src/tools/version_stamp.pl
+++ b/src/tools/version_stamp.pl
@@ -9,10 +9,10 @@
#################################################################
#
-# This script updates the version stamp in configure.in, and also in assorted
+# This script updates the version stamp in configure.ac, and also in assorted
# other files wherein it's not convenient to obtain the version number from
# configure's output. Note that you still have to run autoconf afterward
-# to regenerate configure from the updated configure.in.
+# to regenerate configure from the updated configure.ac.
#
# Usage: cd to top of source tree and issue
# src/tools/version_stamp.pl MINORVERSION
@@ -74,7 +74,7 @@
# (this also ensures we're in the right directory)
my $aconfver = "";
-open(my $fh, '<', "configure.in") || die "could not read configure.in: $!\n";
+open(my $fh, '<', "configure.ac") || die "could not read configure.ac: $!\n";
while (<$fh>)
{
if (m/^m4_if\(m4_defn\(\[m4_PACKAGE_VERSION\]\), \[(.*)\], \[\], \[m4_fatal/
@@ -86,13 +86,13 @@
}
close($fh);
$aconfver ne ""
- || die "could not find autoconf version number in configure.in\n";
+ || die "could not find autoconf version number in configure.ac\n";
-# Update configure.in and other files that contain version numbers
+# Update configure.ac and other files that contain version numbers
my $fixedfiles = "";
-sed_file("configure.in",
+sed_file("configure.ac",
"-e 's/AC_INIT(\\[PostgreSQL\\], \\[[0-9a-z.]*\\]/AC_INIT([PostgreSQL], [$fullversion]/'"
);
--
2.27.0
v1-0002-Update-to-Autoconf-2.69b.patch.bz2application/x-bzip2; name=v1-0002-Update-to-Autoconf-2.69b.patch.bz2Download
BZh91AY&SYT��������������������a��}��6��v�� ���P��}���O��`��T4�]�
n�Cs}���&�������4
3hwk���6^�� /a3� [{�E��{��@��|���)LqHl����i�w��i��E�Pdz�RC�}����l�wOu�Q �^�@.��tQ���5�h� O=0�@WO�����m� �P
(:�
���3�{�jR��>��B�y��'�5W8 E��"[��j����� �j�`ZA��
�)���U�A�� ����yO�}�>���m��Wo��{���@=�\ t��: .{� Hv��� Y� �� �s��v���X������e��� M�2j�cc�;����{����e�]���&����SO�T�$]5��������5i��;�{�|��o���n��������\��������\��gQ��T6��������W�k'�N�E�c`I
��<,|��m�����z�=����/bd� �[�����;����)T�m�����9�������a)!Og b��tJSajZh{�����{h*e���)M�p���)��\S��{l�I�����wR���K��������J��Zt����\Z6eu��V�v<Y���������V=���i���q����+����}��lwf7{�r���v�ju��g��A.�:j�t�y�;�2�[�
�9T�*�3�C���+e����C=u�]� [D�����������m�}����B6���_Z�';��s�u�I{k��&�m_8�N����j������+�\N���n�^������G^� B���t�j=����z�l�c�m��V��[�J(�V��7Y��nj���*Dh L�4d4 ����T�I�����DM4��<�SO�������
�
��)�&�S���z��S�F� �B
=OQ��C �@��Ii1�<����F�����C&� � ��ha�4��f��y'����� �1L�MLjz��HA ���� S���l#h��F����O"a=M ������%�g���O���I#�*$�$?c��1�\��r���R�>���md���6���S��S2h`��f1.�([��3?�SXc�4$�����^����������f��h3cJ;GA���.�������0�|����?3���Z?�t���Q�7�_�������P?������T���[M:�����������^�wI���k��3S���&�����������S������Z.N�� ���&R�v�^��`���>�=K*��h����}������k�����(����O�����������}���<��D��� ���;��D�W�5�K�^�bs��Zf�6Q�-)1�����W.9�o9�6�����CQF����~��eQ�{@�*_dH����yJPwN�g�0����������M���ux���u9��Id��Ii�C�YV�2$���Y�q�8�����
�������a����o����]|�����A����(�Pa4;I��C ���6��j��zu�m�����X~t_�7��<'[^$�E����5�{oo�|N�����z��������i2���8�Uf�����!���������z��/ _���V����d7gd��i�[��sB2l���AA���9�����\1 ^��X�;� i�$s% �����t�^��h�_������S�A�d�i}~�����7 �� ��-��&
w�ca��n^[�����jm���q��_o�F�m�'�F�����P�� =�Hf����f���3���� �kU�k�[
i�1pk��.b.E���3Xg��&���#�*�C�0�r�[�Zni� R����"����c��� ���f��BE~vKP���YYK��}���D�5�����O���w�]���KL��Y4��u(��f��E�e�<]��lx
�M�;�������i���Yu H��da rEl`���������u�n����OH�O��� ���:cyb�����Q�d������o��� -(�M���O��M���
7��g�"��N�'��U����vm�3�����4�\Gxi#DV�$��fbN`Oe�T���\��-iC#0p%��C3j`������t��)�3��xJDK����\s�#<m��3����������oy�`sE�W� h�<4�U6fU@ �sU��
�_-�z���~�������E��e����f���\/������{�!R@�fa����t�(H��Di��i�X�}bx����~k=��e��� ��0�sD���k����!�����O����{�����?�I��Y�l�����H0����>�v��4��W1)$r��d��4�qO�M����H#kF���tW��?���� � @ $ D@BI ~O<�����G8s���"!��d�d�� �E�6���K�z4���T���E��%��%�m������F�h��1.��
��6������E`7�wv�P��Z����A�F���v56.�������ea�h��������4�LDg+�d�&�fc��(�<���.{U��8n�^}N�x�.K�����^�'�`����v#�
�tn���a���M��Fc�����[���g�_��'����x�����A�I�3�?�W#c�a���vk�����D�y��o��I0��^�D���{b:���]���f8�������� �.�&���A�m`����xz�r�LZ�����W�x�~]���^��~,����H���)HVA�|���> �������/<g���F����;�������"�&U �� �"t0���vc(5M���<!��~�dik���G�!.��<X�<��� -#���5�)�� ��k�{9m�l4����6
�m@H�G���sd����t�5n���!�a��uy>�A�V�^ ��wxkV�c)���N�4�]�b�a��zwu��M���pc�a�g�� �~�"B"��]�����Hrc��D�Q �o�A$�Gmq��u���i�
c�z��u�\�������W��������r��b�����"iQ�8bV�����(����u6^���JmI��S�s�.XuFu����Zu��(�b�8�� ��B�������#FCu�BBX�l) >m�`�;$���#�F�>�)+9��j!�+�������3��zxkS�#�-��c�p��"�SY�T�+|v�b�t+��:�>��h�_��q�#�p�J���V�39H|�Q���\��x���<������d~���&���E �7���Hmo�q�����@��1k�s3�.kOm!��j�e������m�|��5�S�[���%Q!�l����I7���I�/�.J�ru��>���n��IC�����M��vvq; �pq�0��������&�����O���]_F�����6�5��0������^�m�-k+��.��,������x���'d��|l%.�L��H�N"�s��DPTh������@� �rhrI4{��O�_}%�F=�����4Y��{���"{5��|H�@��b��$�i��\#lcv��b�=�~�/JY^m�������� I�2�B>����c[�{�e��|~?Mj�',!��T���c���p6-}.`!��\�
�I�1�s��j 2E]��0;#��cB,�;����� S'��9i�n�B�$.bZQ��d���|���fT�~�m6O<��%g����[�zk%�?�nQ�fC!���:ru�W��5�������Zd��F�NB���O,$�A�X\`j5KH����-�������a��h=�u���^#��P�9�� K��m��X�$�v�}�_�/
���?0dqq/���<��2P�E����6�f��U�����,�L
Qa�"