Re: Accessibility for person with a motor disability
Le 20/03/2018 à 17:33, Alex ARNAUD a écrit : Hello Thibaut, Le 20/03/2018 à 11:14, Thibaut Paumard a écrit : Le 20/03/2018 à 10:35, Alex ARNAUD a écrit : What is as you know the most efficient way to write text with a head-tracking software? Dasher comes to mind: I've tested it, looks good to me. Is Dasher should be configured to replace the keyboard when I open a text edition field? I've found how to write text but it's only from the dasher window so imagine if I would like to enter text on Firefox, how I can do that? Maybe there is a documentation I could look on? (I've already read some documentation I've found on the dasher website). Dear Alex, Dasher has a "direct mode" that you can activate from le File menu. In this mode, you can click in a text input widget in any application and come back to dasher window to type text that will directly appear in this widget. I have typed part of this e-mail this way in thunderbird using dasher. I don't use dasher on a daily basis myself, so I can't judge whether it's reliable or practical for daily use. For sure it does not play nice with mouse or sloppy focus. Also, due to how it is implemented, direct mode works only under X11, not in Wayland: https://bugzilla.gnome.org/show_bug.cgi?id=778151 So by default direct mode works in Debian Stretch (current stable), but not in Buster (current unstable). Kind regards, Thibaut.
Re: Accessibility for person with a motor disability
Le 20/03/2018 à 10:35, Alex ARNAUD a écrit : What is as you know the most efficient way to write text with a head-tracking software? Dear Alex, Dasher comes to mind: https://en.wikipedia.org/wiki/Dasher_(software) Kind regards, Thibaut.
Re: Bug#852149: Re : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running
Le 02/03/2017 à 11:26, Thibaut Paumard a écrit : > I attach a corrected patch that does apply cleanly. I am currently > building the package under stretch and will upload it to some public > space when done. > Hi, I've uploaded the patched firefox-esr, built on stretch, here: https://people.debian.org/~thibaut/firefox-esr/ All the .deb are there. The main package is at: https://people.debian.org/~thibaut/firefox-esr/firefox-esr_45.7.0esr-4+a11y1_amd64.deb This is not a repository, you'll need to download the individual packages manually and install them e.g. with sudo gdebi firefox-esr_45.7.0esr-4+a11y1_amd64.deb It wpuld be great if some affected user could try this package and see whether this fixes it for them. Regards, Thibaut.
Re: Bug#852149: Re : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running
Le 01/03/2017 à 23:54, Mike Hommey a écrit :
> Thanks. This points to
> https://bugzilla.mozilla.org/show_bug.cgi?id=1273020
>
> which points to
> https://hg.mozilla.org/integration/mozilla-inbound/rev/8bfdf5dfcf6bcf706fea4cda201f72ffc0c69c4a
>
> Can someone try to apply this patch and see how it goes for them?
Hi,
This patch does not apply cleanly on firefox-esr (45.7.0esr-4).
I attach a corrected patch that does apply cleanly. I am currently
building the package under stretch and will upload it to some public
space when done.
I won't be able to test though, as I can't reproduce the crash.
Regards, Thibaut.
diff --git a/accessible/generic/ApplicationAccessible.h b/accessible/generic/ApplicationAccessible.h
--- a/accessible/generic/ApplicationAccessible.h
+++ b/accessible/generic/ApplicationAccessible.h
@@ -55,39 +55,45 @@ public:
virtual void InvalidateChildren() override;
// ActionAccessible
virtual KeyBinding AccessKey() const override;
// ApplicationAccessible
void AppName(nsAString& aName) const
{
-nsAutoCString cname;
-mAppInfo->GetName(cname);
-AppendUTF8toUTF16(cname, aName);
+if (mAppInfo) {
+ nsAutoCString cname;
+ mAppInfo->GetName(cname);
+ AppendUTF8toUTF16(cname, aName);
+}
}
void AppVersion(nsAString& aVersion) const
{
-nsAutoCString cversion;
-mAppInfo->GetVersion(cversion);
-AppendUTF8toUTF16(cversion, aVersion);
+if (mAppInfo) {
+ nsAutoCString cversion;
+ mAppInfo->GetVersion(cversion);
+ AppendUTF8toUTF16(cversion, aVersion);
+}
}
void PlatformName(nsAString& aName) const
{
aName.AssignLiteral("Gecko");
}
void PlatformVersion(nsAString& aVersion) const
{
-nsAutoCString cversion;
-mAppInfo->GetPlatformVersion(cversion);
-AppendUTF8toUTF16(cversion, aVersion);
+if (mAppInfo) {
+ nsAutoCString cversion;
+ mAppInfo->GetPlatformVersion(cversion);
+ AppendUTF8toUTF16(cversion, aVersion);
+}
}
protected:
virtual ~ApplicationAccessible() {}
// Accessible
virtual void CacheChildren() override;
virtual Accessible* GetSiblingAtOffset(int32_t aOffset,
nsresult *aError = nullptr) const override;
Re: Re : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running
Dear Firefox maintainers, We have several users confirming this bug: https://lists.debian.org/debian-accessibility/2017/02/msg00062.html More precisely and although I have not been able to reproduce it, it appears that for those users, firefox-esr crashes upon exit when the orca screen reader is running. The symptom that firefox crashes is the crash report window popping-up. The original bug reporter also mentioned in the thread above that he is using orca as well. Kind regards, Thibaut. Le 01/03/2017 à 10:35, MENGUAL Jean-Philippe a écrit : > Hi, > > I have reported this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852149 > > You should then reply to this bug. I know I submitted in it two kinds of > problems, but we easily can focus on the crash. > > I am not sure I precised I use Orca, could be useful to mention, indeed. > > Regards > > > Jean-Philippe MENGUAL > > HYPRA, progressons ensemble > > Tél.: 01 84 73 06 61 > > Mail: cont...@hypra.fr > > Site Web: http://www.hypra.fr > > - Thibaut Paumard <thib...@debian.org> a écrit : >> Le 24/02/2017 à 17:35, am_d...@fastmail.fm a écrit : >>> Hello, >>> I have all the latest packages installed for the testing release. I >>> notice that almost every time I close firefox-esr, I get a message that >>> it has crashed. I guess I am not sure if this is an accessibility >>> related issue. The reason I think it might be is because if these >>> crashes were happening without Orca running, many other users would have >>> noticed it. The test case that i have is to just open Firefox and close >>> it. This seems to cause a crash in most cases for me with a resulting >>> dialog asking if I want to send crash results to Mozilla. If I use the >>> Firefox package from experimental, the crashes are gone. I thought it >>> might be interesting to see if any Orca users can reproduce this and if >>> any sighted users can confirm whether the crash occurs when Orca is off. >>> I can reproduce on both an AMD and Intel machine. Thanks >>> >> >> Hi, we have a second user who confirms the crash when orca is running. >> He unfortunately cannot with orca off. I'm forwarding his two mails with >> permission below. >> >> Dear am_dxer, can you report this as a bug against firefox-esr with >> X-Debbugs-CC to this list? >> >> Can you try also with firefox non-ESR? >> >> Regards, Thibaut. >> >> >> Message transféré >> Sujet : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca >> running >> Date : Mon, 27 Feb 2017 08:44:51 -0500 >> De : Doug Smith <romans1...@minister.com> >> Répondre à : romans1...@minister.com >> Pour : Thibaut Paumard <thib...@debian.org> >> >> It happens over here almost all the time. I know that the browser >> didn't crash because I just used it and exited from it only seconds >> before the report dialogue comes up here. >> >> Interesting. >> >> >> Message transféré >> Sujet : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca >> running >> Date : Mon, 27 Feb 2017 14:05:15 -0500 >> De : Doug Smith <romans1...@minister.com> >> Pour : Thibaut Paumard <thib...@debian.org> >> >> >> >> This is with the screen reader on and I would not be able to test with >> it off. I just thought it was something I had set when I had a system >> with firefox 50 on it and it carried over to my .mozilla directory which >> I kept for this system so that I could hold onto some web site logins. >> I don't know what's causing it but it is annoying. >> >> >> Sorry I can't help. >> >> >
Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running
Le 24/02/2017 à 17:35, am_d...@fastmail.fm a écrit : > Hello, > I have all the latest packages installed for the testing release. I > notice that almost every time I close firefox-esr, I get a message that > it has crashed. I guess I am not sure if this is an accessibility > related issue. The reason I think it might be is because if these > crashes were happening without Orca running, many other users would have > noticed it. The test case that i have is to just open Firefox and close > it. This seems to cause a crash in most cases for me with a resulting > dialog asking if I want to send crash results to Mozilla. If I use the > Firefox package from experimental, the crashes are gone. I thought it > might be interesting to see if any Orca users can reproduce this and if > any sighted users can confirm whether the crash occurs when Orca is off. > I can reproduce on both an AMD and Intel machine. Thanks > Hi, we have a second user who confirms the crash when orca is running. He unfortunately cannot with orca off. I'm forwarding his two mails with permission below. Dear am_dxer, can you report this as a bug against firefox-esr with X-Debbugs-CC to this list? Can you try also with firefox non-ESR? Regards, Thibaut. Message transféré Sujet : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running Date : Mon, 27 Feb 2017 08:44:51 -0500 De : Doug Smith <romans1...@minister.com> Répondre à : romans1...@minister.com Pour : Thibaut Paumard <thib...@debian.org> It happens over here almost all the time. I know that the browser didn't crash because I just used it and exited from it only seconds before the report dialogue comes up here. Interesting. Message transféré Sujet : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running Date : Mon, 27 Feb 2017 14:05:15 -0500 De : Doug Smith <romans1...@minister.com> Pour : Thibaut Paumard <thib...@debian.org> This is with the screen reader on and I would not be able to test with it off. I just thought it was something I had set when I had a system with firefox 50 on it and it carried over to my .mozilla directory which I kept for this system so that I could hold onto some web site logins. I don't know what's causing it but it is annoying. Sorry I can't help.
Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running
Le 24/02/2017 à 17:35, am_d...@fastmail.fm a écrit : > Hello, > I have all the latest packages installed for the testing release. I > notice that almost every time I close firefox-esr, I get a message that > it has crashed. I guess I am not sure if this is an accessibility > related issue. The reason I think it might be is because if these > crashes were happening without Orca running, many other users would have > noticed it. The test case that i have is to just open Firefox and close > it. This seems to cause a crash in most cases for me with a resulting > dialog asking if I want to send crash results to Mozilla. If I use the > Firefox package from experimental, the crashes are gone. I thought it > might be interesting to see if any Orca users can reproduce this and if > any sighted users can confirm whether the crash occurs when Orca is off. > I can reproduce on both an AMD and Intel machine. Thanks > Hi, I cannot reproduce this, whether orca is running or not. Kind regards, Thibaut.
Bug#852699: dasher -- useless under GNOME (Wayland)
Le 03/02/2017 à 14:22, Samuel Thibault a écrit :
> Thibaut Paumard, on Fri 03 Feb 2017 13:09:37 +0100, wrote:
>> A work-around is to run dasher with GDK_BACKEND=x11:
>>
>> GDK_BACKEND=x11 dasher
>
> Perhaps we (and upstream) should do this by default for now?
>
> Samuel
>
Dear Samuel,
It looks fairly easy to disable the wayland backend. I don't have the
time to try right now, but it should be enough to call
gdk_set_allowed_backends ("x11");
just before gtk_init().
Unfortunately I doubt such change can make it in stretch, with the full
freeze happening in two days.
Regards, Thibaut.
--
* Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) *
* Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) *
smime.p7s
Description: Signature cryptographique S/MIME
Bug#852699: dasher -- useless under GNOME (Wayland)
Le 03/02/2017 à 13:09, Thibaut Paumard a écrit : > GDK_BACKEND=x11 dasher > > Then dasher mostly works. Well, direct mode only works with X11 windows.
dasher: canonical git repository and issue tracker
Dear Dasher developers, I am the new maintainer for Dasher in Debian GNU/Linux. I am confused by the information on Dasher's what's new page: http://www.inference.phy.cam.ac.uk/dasher/WhatsNew.html which links to https://github.com/ipomoena/dasher/releases. Which of the two github repositories should be considered the canonical one: https://github.com/GNOME/dasher/ https://github.com/ipomoena/dasher/ Also, the README file still instructs filing bugs at http://bugzilla.gnome.org/ but all recent bug reports seem to have been filed at: https://github.com/ipomoena/dasher/issues Where should I report issues? Kind reports, Thibaut.
Bug#852699: dasher -- useless under GNOME (Wayland)
Control: retitle -1 dasher -- does not work with wayland backend Dear team, Le 26/01/2017 à 15:37, Thibaut Paumard a écrit : > Dasher works well under X11 (e.g. "GNOME" or "Cinnamon" session) but > does nothing useful under the "GNOME (Wayland)" session. Following the instructions at: https://fedoraproject.org/wiki/How_to_debug_Wayland_problems I have been able to determine that the same symptoms also apply when running in weston. A work-around is to run dasher with GDK_BACKEND=x11: GDK_BACKEND=x11 dasher Then dasher mostly works. It cannot read the pointer position when the pointer is out of the dasher window, so one should tick the option "Pause outside canvas" in the "Control" tab of the "Preferences" window. Regards, Thibaut.
Bug#852701: [dasher] "direct mode" toggle can be inverted
Package: dasher Version: 5.0.0~beta~repack-1 Severity: minor Tags: upstream --- Please enter the report below this line. --- Dear team, Starting version 5, dasher now remembers whether it was in direct mode when quitting. However the corresponding toggles are inverted if dasher is started already in directed mode, i.e. the button in the main interface and the File menu toggle always start unselected, and selecting them reverts the behaviour to non-direct, but the display to direct. Regards, Thibaut. --- System information. --- Architecture: Kernel: Linux 4.8.0-2-amd64 Debian Release: 9.0 990 stable repos.fds-team.de 990 stable dl.google.com 900 testing debian.ens-cachan.fr --- Package information. --- Depends (Version) | Installed ===-+- libatk1.0-0 (>= 1.12.4) | libatspi2.0-0 (>= 2.9.90) | libc6 (>= 2.14) | libcairo-gobject2 (>= 1.10.0) | libcairo2 (>= 1.2.4) | libdbus-1-3 (>= 1.9.14) | libexpat1(>= 2.0.1) | libgcc1 (>= 1:3.0) | libgdk-pixbuf2.0-0 (>= 2.22.0) | libglib2.0-0(>= 2.37.3) | libgtk-3-0 (>= 3.0.0) | libice6 (>= 1:1.0.0) | libpango-1.0-0 (>= 1.14.0) | libpangocairo-1.0-0 (>= 1.14.0) | libsm6 | libspeechd2 (>= 0.7.1) | libstdc++6 (>= 5.2) | libx11-6 | libatk-adaptor | dasher-data (= 5.0.0~beta~repack-1) | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#852699: dasher -- useless under GNOME (Wayland)
Package: dasher Version: 4.11+git20130508.adc653-3 Severity: wishlist Tags: upstream --- Please enter the report below this line. --- Dear team, Dasher works well under X11 (e.g. "GNOME" or "Cinnamon" session) but does nothing useful under the "GNOME (Wayland)" session. It looks like Dasher can simply not read the pointer position. Clicking once updates the position, but then you have to click on some other window and come back for another click to be taken into account by dasher. See: https://github.com/ipomoena/dasher/issues/103 Regards, Thibaut. --- System information. --- Architecture: Kernel: Linux 4.8.0-2-amd64 Debian Release: 9.0 --- Package information. --- Depends (Version) | Installed =-+-== gconf-service | 3.2.6-4 libatk1.0-0 (>= 1.12.4) | libatspi2.0-0 (>= 2.9.90) | libbonobo2-0 (>= 2.32.1-3~) | libc6 (>= 2.14) | libcairo-gobject2 (>= 1.10.0) | libcairo2 (>= 1.2.4) | libdbus-1-3 (>= 1.9.14) | libexpat1 (>= 2.0.1) | libgcc1(>= 1:3.0) | libgconf-2-4 (>= 3.2.5) | libgdk-pixbuf2.0-0(>= 2.22.0) | libglib2.0-0 (>= 2.37.3) | libgnome-speech7 | libgtk-3-0 (>= 3.0.0) | libice6 (>= 1:1.0.0) | liborbit-2-0 (>= 1:2.14.10) | libpango-1.0-0 (>= 1.14.0) | libpangocairo-1.0-0 (>= 1.14.0) | libsm6 | libstdc++6 (>= 5.2) | libx11-6 | libatk-adaptor | dasher-data (= 4.11+git20130508.adc653-3) | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#797891: dasher: Segfault on toggling "Control Mode" check box
Le 26/01/2017 à 14:16, Simon Kainz a écrit : > Hello, > > I just build 5.0.0~beta~repack-2 and tested it, it works. > > It tried toggling it on/off, also fast, but could not crash dasher. > > So this bug may be closed. > Thanks for your feedback. Regards, Thibaut. > Thanks & Bye, > > Simon > > > Am 2017-01-25 um 16:52 schrieb Thibaut Paumard: >> control: tag -1 confirmed >> >> Dear Simon, >> >> I recently adopted dasher and am now processing the backlog of bug reports. >> >> I can confirm the SEGFAULT, but only if I click repeatedly and fast on >> the toggle. >> >> In you experience, it the bug easy to reproduce or do you have to >> insist? Does the bug break some functionality, or is it merely an >> inconvenience that you have to restart dasher? Could you also try the >> new version (currently in unstable, hopefully in testing within a coupld >> of days): 5.0.0~beta~repack-2 and tell me whether it behaves better for >> you? (I have tried and seen that the SEGFAULT is possible to trigger). >> >> Regards, Thibaut. >> > signature.asc Description: OpenPGP digital signature
Bug#767348: dasher: Direct mode does not work (gnome3)
Control: tag -1 unreproducible Le 26/01/2017 à 12:22, Thibaut Paumard a écrit : > Le 25/01/2017 à 18:03, Matthias Urlichs a écrit : > >> However, other problems (which probably deserve their own bug report but >> I'm in a hurry): >> >> * turn on File > Direct mode. Quit Dasher. Start it again. Note that the >> checkbox in the File menu is now inverted (i.e. Direct Mode is enabled >> but the checkbox is off, and vice versa) >> I can confirm this, only on 5.0... not 4.11... I will file the appropriate bug report soonish. >> * as I type my email in Thunderbird, dasher doesn't pick up what's >> behind the cursor. Works with gedit or terminal. Doesn't seem to work >> with KDE programs (tested: knotes). For me it all works well (under GNOME3 and cinnamon), please feel free to file a bug report with details about your environment. >> * "pause outside of canvas" option doesn't work when leaving the canvas >> to the right. Works for me, same as above. One set-up that looks completely broken for me is in GNOME Wayland. I mention that in case you are using it. I'll also file that bug soon. In any case, hanks for you help! I will close this bug within a couple of days. As usual, if if can be reproduced, please reopen. Regards, Thibaut. > > Thanks Matthias. That would help if you could check whether those > problems also exist with 4.11+... still in testing. I'll try as well, > time permitting... > > > Regards, Thibaut. >
Bug#767348: dasher: Direct mode does not work (gnome3)
Le 25/01/2017 à 18:03, Matthias Urlichs a écrit : > However, other problems (which probably deserve their own bug report but > I'm in a hurry): > > * turn on File > Direct mode. Quit Dasher. Start it again. Note that the > checkbox in the File menu is now inverted (i.e. Direct Mode is enabled > but the checkbox is off, and vice versa) > > * as I type my email in Thunderbird, dasher doesn't pick up what's > behind the cursor. Works with gedit or terminal. Doesn't seem to work > with KDE programs (tested: knotes). > > * "pause outside of canvas" option doesn't work when leaving the canvas > to the right. > Thanks Matthias. That would help if you could check whether those problems also exist with 4.11+... still in testing. I'll try as well, time permitting... Regards, Thibaut.
Bug#797891: dasher: Segfault on toggling "Control Mode" check box
control: tag -1 confirmed Dear Simon, I recently adopted dasher and am now processing the backlog of bug reports. I can confirm the SEGFAULT, but only if I click repeatedly and fast on the toggle. In you experience, it the bug easy to reproduce or do you have to insist? Does the bug break some functionality, or is it merely an inconvenience that you have to restart dasher? Could you also try the new version (currently in unstable, hopefully in testing within a coupld of days): 5.0.0~beta~repack-2 and tell me whether it behaves better for you? (I have tried and seen that the SEGFAULT is possible to trigger). Regards, Thibaut.
Bug#767348: dasher: Direct mode does not work (gnome3)
control: tag -1 moreinfo control: thanks Dear Matthias, I recently adopted dasher and am processing the backlog of bug reports. I know it's been a while since you filed this report and nobody apparently reacted, but I would appreciate if you could confirm whether it is still valid: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767348 I cannot reproduce it in Debian stretch, using version 4.11+git20130508.adc653-3 which is very close to the one on which you reported the bug. Kind regards, Thibaut.
Bug#839836: ITP: dasher -- A graphical predictive text input system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: wnpp Severity: wishlist Owner: Thibaut Paumard <thib...@debian.org> * Package name: dasher Version : 5.0 Upstream Author : The Dasher Project * URL : http://www.inference.phy.cam.ac.uk/dasher/ * License : GPL Programming Lang: C++ Description : A graphical predictive text input system Dasher is an information-efficient text-entry interface, driven by natural continuous pointing gestures. Dasher is a competitive text-entry system wherever a full-size keyboard cannot be used - for example, * on a palmtop computer * on a wearable computer * when operating a computer one-handed, by joystick, touchscreen, trackball, or mouse * when operating a computer with zero hands (i.e., by head-mouse or by eyetracker). The eyetracking version of Dasher allows an experienced user to write text as fast as normal handwriting - 25 words per minute; using a mouse, experienced users can write at 39 words per minute. Dasher uses a more advanced prediction algorithm than the T9(tm) system often used in mobile phones, making it sensitive to surrounding context. This package has recently been removed from Debian for the previous maintainer did not have enough time to foster it. However this package is a necessity for certain users with disabilities. I intend on maintaining it presumably within the debian-accessibility team. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJX9SeSAAoJEJOUU0jg3ChApYYP/iPeaiFe3GCG/WrrE9kI2L+E EG2uLv2HorwV+Bet23jt4kYAaa4eX6JFTJv3g0D67hVZyN4c8ol+JwNMpCjk6uP8 Aer/hrVCYCLWpRYwqAOVAOxC2796syBl2/JgjGMwWdUYUR/8Ylk3dPa+aJKui2cN ItxaY1rE3hEePT4CRkTI4EaFNvItYS4O4A7zG8ssA0iO42aBnWsKruWLksdnXmH0 9E3VJvc7EMh6uIQoq5N2u3tpOet7qqMR+XdpLpZYIJxHUqqavbQqfTcSyosvxoB3 8lK91PEZNEjsVtt9pP95D3dWKgSnXRhzjLG04RWzLyaa5ABLtV5oiFIAjrHuJ3Xb I2fvrMHweVgoqlwQrZ48sQ7V2tvP7NcbC0Q55U4boZOm0cjNwuOTUYuZo/9CXTp+ TnIhKLOgdVzBMwX/3r5VkmXZh6HPQjjvuQc/hH2xdJjflLbn3Mr5kCbfNnvE+KjW 31rCXcPZQ4BQad0ByfBZbXFL5gVv0ZPSwf6VB6aMzxAVYi30zmb//XbK1kv4Hlhf Eg6M/dLwxdyTZ/xWh9UPYY//WqQckXA/u9U1v1ob6UG/olNAU0jqmqVHbnB3FVs5 uTEfbC2g6bhb9koKXLWO64Ggsem/9avLKnJ8RoPMkRYIUnlOHddu+968TG8n2OrR NxR0YczKoBIiMppZ+Gwb =sngp -END PGP SIGNATURE-
