From gsteemso at gmail.com Thu Aug 8 05:56:43 2024 From: gsteemso at gmail.com (Gordon Steemson) Date: Wed, 7 Aug 2024 20:56:43 -0700 Subject: Errors compiling libgpg-error Message-ID: Hello all, I am attempting to update a series of very old package-manager configuration files for the various parts of GnuPG, and have hit two snags when experimentally compiling the first package of the collection, `libgpg-error`. First, a function "my_exec", in the file "spawn-posix.c", assigns a value to a variable "environ". This variable appears nowhere else in the source code of this package tarball, and nothing is done with it after the assignment statement. I patched the file to delete the offending assignment statement, and it now compiles; however I see in the list archives that someone who encountered a similar problem in another of GnuPG's components declared it external instead, which apparently also worked. What is the story behind this variable, and why is it not apparently declared anywhere? Second, perhaps out of a sense of obsessive completism, I tried to enable the ./configure option for timestamped logging. This resulted in an undeclared macro or some such (it is called "CLOCK_REALTIME") jamming the compiler. This macro, or preprocessor constant or whatever it is, likewise does not appear anywhere else in the source code (at least according to grep). Where is it supposed to be defined? G. From gniibe at fsij.org Thu Aug 8 08:45:23 2024 From: gniibe at fsij.org (Niibe Yutaka) Date: Thu, 08 Aug 2024 15:45:23 +0900 Subject: Errors compiling libgpg-error In-Reply-To: References: Message-ID: <87frrfjyws.fsf@jumper.gniibe.org> Hello, Gordon Steemson wrote: > What is the story behind this variable, and why is it not apparently > declared anywhere? It's defined in POSIX system. A reference is: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html > Where is it supposed to be defined? time.h should define it in POSIX system. See: https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html IIUC, it's issues for POSIX compatibilities. -- From wk at gnupg.org Thu Aug 8 09:00:10 2024 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 Aug 2024 09:00:10 +0200 Subject: Errors compiling libgpg-error In-Reply-To: (Gordon Steemson via Gnupg-devel's message of "Wed, 7 Aug 2024 20:56:43 -0700") References: Message-ID: <87zfpncxdx.fsf@jacob.g10code.de> Hello! On Wed, 7 Aug 2024 20:56, Gordon Steemson said: > apparently also worked. What is the story behind this variable, and > why is it not apparently declared anywhere? ENVIRON is a standard Unix variable pointing to the environment data block. That is what getenv works on. Meanwhile this varibale is declared in unistd.h but before that it was common to declare it in your source. > Second, perhaps out of a sense of obsessive completism, I tried to > enable the ./configure option for timestamped logging. This resulted > in an undeclared macro or some such (it is called "CLOCK_REALTIME") > jamming the compiler. This macro, or preprocessor constant or That is define in time.h and part of the clock_gettime function . I'll check whether we really need it. Thanks for reporting. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From tobias at stoeckmann.org Tue Aug 13 21:47:21 2024 From: tobias at stoeckmann.org (Tobias Stoeckmann) Date: Tue, 13 Aug 2024 21:47:21 +0200 Subject: [PATCH pinentry 2/2] Fix typos Message-ID: <6ylqunkbfrxpyrqxeukle6hikgza67ks5feftom3bg2ubcq6cu@st2kpllvn4vl> Typos found with codespell. --- Makefile.am | 2 +- build-aux/texinfo.tex | 2 +- doc/pinentry.texi | 2 +- doc/texinfo.tex | 2 +- pinentry/argparse.c | 8 ++++---- pinentry/pinentry-curses.c | 4 ++-- pinentry/pinentry.c | 2 +- tqt/secqinternal_p.h | 2 +- tqt/secqlineedit.cpp | 4 ++-- tqt/secqstring.cpp | 4 ++-- tqt/secqstring.h | 2 +- 11 files changed, 17 insertions(+), 17 deletions(-) diff --git a/Makefile.am b/Makefile.am index cf51495..3801ce5 100644 --- a/Makefile.am +++ b/Makefile.am @@ -175,7 +175,7 @@ release: $(MAKE) distcheck; \ echo "/* Build finished at $$(date -uIseconds) */" ;\ echo "/*" ;\ - echo " * Please run the final step interactivly:" ;\ + echo " * Please run the final step interactively:" ;\ echo " * make sign-release" ;\ echo " */" ;\ ) 2>&1 | tee "$(RELEASE_NAME).buildlog" diff --git a/build-aux/texinfo.tex b/build-aux/texinfo.tex index 1e6de89..2bdb643 100644 --- a/build-aux/texinfo.tex +++ b/build-aux/texinfo.tex @@ -520,7 +520,7 @@ \fi } -% Evironment mismatch, #1 expected: +% Environment mismatch, #1 expected: \def\badenverr{% \errhelp = \EMsimple \errmessage{This command can appear only \inenvironment\temp, diff --git a/doc/pinentry.texi b/doc/pinentry.texi index c81cfa4..37925e4 100644 --- a/doc/pinentry.texi +++ b/doc/pinentry.texi @@ -806,7 +806,7 @@ Tooltip for an action that would reveal the entered password. @item @code{default-tt-hide} Tooltip for an action that would hide the password revealed -by the action labeld with @code{default-tt-visi} +by the action labeled with @code{default-tt-visi} @item @code{default-capshint} A hint to be shown if Caps Lock is on. diff --git a/doc/texinfo.tex b/doc/texinfo.tex index 3f81058..9d273bb 100644 --- a/doc/texinfo.tex +++ b/doc/texinfo.tex @@ -520,7 +520,7 @@ \fi } -% Evironment mismatch, #1 expected: +% Environment mismatch, #1 expected: \def\badenverr{% \errhelp = \EMsimple \errmessage{This command can appear only \inenvironment\temp, diff --git a/pinentry/argparse.c b/pinentry/argparse.c index 58b31e7..3f16e68 100644 --- a/pinentry/argparse.c +++ b/pinentry/argparse.c @@ -32,7 +32,7 @@ /* This file may be used as part of GnuPG or standalone. A GnuPG build is detected by the presence of the macro GNUPG_MAJOR_VERSION. - Some feature are only availalbe in the GnuPG build mode. + Some feature are only available in the GnuPG build mode. */ #ifdef HAVE_CONFIG_H @@ -412,7 +412,7 @@ static void store_alias( ARGPARSE_ARGS *arg, char *name, char *value ) { /* TODO: replace this dummy function with a rea one - * and fix the probelms IRIX has with (ALIAS_DEV)arg.. + * and fix the problems IRIX has with (ALIAS_DEV)arg.. * used as lvalue */ (void)arg; @@ -443,7 +443,7 @@ ignore_invalid_option_p (ARGPARSE_ARGS *arg, const char *keyword) /* Add the keywords up to the next LF to the list of to be ignored options. After returning FP will either be at EOF or the next - character read wll be the first of a new line. The function + character read will be the first of a new line. The function returns 0 on success or true on malloc failure. */ static int ignore_invalid_option_add (ARGPARSE_ARGS *arg, FILE *fp) @@ -1228,7 +1228,7 @@ long_opt_strlen( ARGPARSE_OPTS *o ) * this option * - a description,ine which starts with a '@' and is followed by * any other characters is printed as is; this may be used for examples - * ans such. + * and such. * - A description which starts with a '|' outputs the string between this * bar and the next one as arguments of the long option. */ diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index 8660b0f..86f7cd1 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -1451,12 +1451,12 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) { start_color (); - /* Ncurses has use_default_colors, an extentions to the curses + /* Ncurses has use_default_colors, an extension to the curses library, which allows use of -1 to select default color. */ #ifdef NCURSES_VERSION use_default_colors (); #else - /* With no extention, we need to specify color explicitly. */ + /* With no extension, we need to specify color explicitly. */ if (pinentry->color_fg == PINENTRY_COLOR_DEFAULT) pinentry->color_fg = PINENTRY_COLOR_WHITE; if (pinentry->color_bg == PINENTRY_COLOR_DEFAULT) diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index 904cc4d..3916dd7 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -1760,7 +1760,7 @@ cmd_getpin (assuan_context_t ctx, char *line) /* Note that the option --one-button is a hack to allow the use of old pinentries while the caller is ignoring the result. Given that options have never been used or flagged as an error the new option - is an easy way to enable the messsage mode while not requiring to + is an easy way to enable the message mode while not requiring to update pinentry or to have the caller test for the message command. New applications which are free to require an updated pinentry should use MESSAGE instead. */ diff --git a/tqt/secqinternal_p.h b/tqt/secqinternal_p.h index a05c9c3..b0bbcb6 100644 --- a/tqt/secqinternal_p.h +++ b/tqt/secqinternal_p.h @@ -1,7 +1,7 @@ /**************************************************************************** ** $Id$ ** -** Definition of some shared interal classes +** Definition of some shared internal classes ** ** Created : 010427 ** diff --git a/tqt/secqlineedit.cpp b/tqt/secqlineedit.cpp index da0637a..07f1cdf 100644 --- a/tqt/secqlineedit.cpp +++ b/tqt/secqlineedit.cpp @@ -24,7 +24,7 @@ */ -/* Undo/Redo is disabled, because it uses unsecure memory for the +/* Undo/Redo is disabled, because it uses insecure memory for the history buffer. */ #define SECURE_NO_UNDO 1 @@ -638,7 +638,7 @@ void SecTQLineEdit::setAlignment( int flag ) /*! \obsolete \fn void SecTQLineEdit::cursorLeft( bool, int ) - For compatibilty with older applications only. Use cursorBackward() + For compatibility with older applications only. Use cursorBackward() instead. \sa cursorBackward() */ diff --git a/tqt/secqstring.cpp b/tqt/secqstring.cpp index 82dd918..d8aef56 100644 --- a/tqt/secqstring.cpp +++ b/tqt/secqstring.cpp @@ -760,7 +760,7 @@ uchar *SecTQString::utf8() const if (u > 0xffff) { // if people are working in utf8, but strings are encoded in eg. latin1, the resulting // name might be invalid utf8. This and the corresponding code in fromUtf8 takes care - // we can handle this without loosing information. This can happen with latin filenames + // we can handle this without losing information. This can happen with latin filenames // and a utf8 locale under Unix. if (u > 0x10fe00 && u < 0x10ff00) { *cursor++ = (u - 0x10fe00); @@ -818,7 +818,7 @@ uchar *SecTQString::utf8() const Returns the TQChar at index \a i by reference, expanding the string with TQChar::null if necessary. The resulting reference can be assigned to, or otherwise used immediately, but becomes invalid - once furher modifications are made to the string. + once further modifications are made to the string. \code SecTQString string("ABCDEF"); diff --git a/tqt/secqstring.h b/tqt/secqstring.h index 9b9f496..4bec31a 100644 --- a/tqt/secqstring.h +++ b/tqt/secqstring.h @@ -117,7 +117,7 @@ public: SecTQString( const SecTQString & ); // impl-shared copy /* We need a way to convert a TQString to a SecTQString ("importing" it). Having no conversion for the other way prevents - accidential bugs where the secure string is copied to insecure + accidental bugs where the secure string is copied to insecure memory. */ SecTQString( const TQString & ); // deep copy SecTQString( const TQChar* unicode, uint length ); // deep copy -- 2.46.0 From tobias at stoeckmann.org Tue Aug 13 21:46:49 2024 From: tobias at stoeckmann.org (Tobias Stoeckmann) Date: Tue, 13 Aug 2024 21:46:49 +0200 Subject: [PATCH pinentry 1/2] Fix typos Message-ID: <6rv6mzmjqon3dn25y35s67vw4kmxzcwmletidlhdzxopguc7zu@kggzn3tthkoe> --- README.GIT | 2 +- pinentry/pinentry.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.GIT b/README.GIT index ee2c638..9b39634 100644 --- a/README.GIT +++ b/README.GIT @@ -3,7 +3,7 @@ If you are building from GIT, run the script ./autogen.sh first, to make sure that you have all the necessary maintainer tools -are installed and to build the actual configuration files. If you +installed and to build the actual configuration files. If you have just checked out from GIT, you should add the option "--force" to autogen.sh so that meta data is noticed by autom4te.cache. Then run diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c index b0184c4..904cc4d 100644 --- a/pinentry/pinentry.c +++ b/pinentry/pinentry.c @@ -241,9 +241,9 @@ pinentry_assuan_reset_handler (assuan_context_t ctx, char *line) -/* Copy TEXT or TEXTLEN to BUFFER and escape as required. Return a +/* Copy TEXT of TEXTLEN to BUFFER and escape as required. Return a pointer to the end of the new buffer. Note that BUFFER must be - large enough to keep the entire text; allocataing it 3 times of + large enough to keep the entire text; allocating it 3 times of TEXTLEN is sufficient. */ static char * copy_and_escape (char *buffer, const void *text, size_t textlen) @@ -392,7 +392,7 @@ pinentry_get_pgmname (void) } -/* Return a malloced string with the title. The caller mus free the +/* Return a malloced string with the title. The caller must free the * string. If no title is available or the title string has an error * NULL is returned. */ char * @@ -1824,7 +1824,7 @@ cmd_message (assuan_context_t ctx, char *line) } -/* Return a staically allocated string with information on the mode, +/* Return a statically allocated string with information on the mode, * uid, and gid of DEVICE. On error "?" is returned if DEVICE is * NULL, "-" is returned. */ static const char * -- 2.46.0 From steffen at sdaoden.eu Wed Aug 14 00:08:10 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 14 Aug 2024 00:08:10 +0200 Subject: [PATCH pinentry 2/2] Fix typos In-Reply-To: <6ylqunkbfrxpyrqxeukle6hikgza67ks5feftom3bg2ubcq6cu@st2kpllvn4vl> References: <6ylqunkbfrxpyrqxeukle6hikgza67ks5feftom3bg2ubcq6cu@st2kpllvn4vl> Message-ID: <20240813220810.EXv75mL6@steffen%sdaoden.eu> Tobias Stoeckmann wrote in <6ylqunkbfrxpyrqxeukle6hikgza67ks5feftom3bg2ubcq6cu at st2kpllvn4vl>: |Typos found with codespell. Btw the wonderful and very much appreciated Jens Schleusener, who drives "Fossies" that can celebrate its thirtieth anniversary this year (Wow! Congratulation!!), has added codespell support for selective archive members some years ago. gnupg is among them, and it might me worth looking into the result: https://fossies.org/linux/misc/gnupg-2.5.0.tar.bz2/codespell.html Gnupg is rated B- (i think that is US style stuff); the released version of my MUA is rated C-, but that likely a codespell bug is. Ah. Ciao! From paul at boddie.org.uk Thu Aug 22 21:18:01 2024 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 22 Aug 2024 21:18:01 +0200 Subject: Showing signatures for exported/unimported keys using the Python GPGME bindings Message-ID: <3305442.ImKIP6uL9k@jason> Hello, I have recently been investigating the Python GPGME bindings, available as python3-gpg in Debian, and translating code that previously invoked the gpg executable directly. Having managed to successfully find my way around the API, I think I have discovered a shortcoming with the bindings. When processing an exported key held in a file, if I use the context's keylist operation, indicating the source as "data" as opposed to the keychain, the operation does not yield signature information for each key. For example, with file f and generator result g: g = context.keylist(source=f) For operations involving the keychain, it is possible to set the mode in order to return signature details, but it does not seem to be possible to set the mode of the operation when a source is indicated. Indeed, the source code for the bindings appears to discard the mode where a source is involved. Here is code from Context.keylist in gpg/core.py: if not source: self.set_keylist_mode(mode) self.op_keylist_start(pattern, secret) else: # ... if not isinstance(source, Data): source = Data(file=source) self.op_keylist_from_data_start(source, 0) However, changing this code to set the mode even with a source indicated (specifying the SIGS and/or SIG_NOTATIONS flags) does not cause the operation to yield signature information. Oddly, the gpg executable will produce this information. For example: gpg --show-keys --with-sig-list keyfile This shows signature details for each of the keys. I tried to search for any previous reports of this behaviour but only found the following discussion thread: "python GPGME bindings and key signatures" https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/034023.html This discusses the retrieval of signature information for keys on the keychain, not from unimported keys residing in files. I wonder if this is a known shortcoming of the API or whether it was a deliberate decision or consequence of some other choice. The discrepancy between the API and gpg itself seems peculiar. Paul P.S. Some kind of quick reference mapping gpg operations to the API would be rather helpful. I see that examples are provided with the bindings, but they are not particularly comprehensive. From wk at gnupg.org Fri Aug 23 10:11:45 2024 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Aug 2024 10:11:45 +0200 Subject: Showing signatures for exported/unimported keys using the Python GPGME bindings In-Reply-To: <3305442.ImKIP6uL9k@jason> (Paul Boddie via Gnupg-devel's message of "Thu, 22 Aug 2024 21:18:01 +0200") References: <3305442.ImKIP6uL9k@jason> Message-ID: <87y14nbqv2.fsf@jacob.g10code.de> Hi Paul, you might have noticed that we don't have a real maintainer for the Python bindings anymore. The last maintainer did a lot on the documentation front but less on the actual inner workings. Instead of having used the convient SWIG based bindings we should have done a manual binding to make sure that we have a stable API (and less compiler warning ;-). It is more work of course but counting in all the problems and the endless hours of fixing stuff this would have been better in the end. > P.S. Some kind of quick reference mapping gpg operations to the API would be > rather helpful. I see that examples are provided with the bindings, but they The original SWIG idea was that there is no need for a separate documentation. The higher level and more pythonese API was added latter and is indeed not comprehensive. It might be important for your considerations that we plan to split off the language bindings into separate repos and tarballs. The main driver for this is that the Qt folks prefer to use cmake and having both build systems (cmake and autotools) is not easy for the maintainers. The Python bindings will thus also be split into a separate library and it will allow to have a maintainer who does not need to follow the gpgme development all the day but instead rely on the stable GPGME API. See https://dev.gnupg.org/T7262 Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From paul at boddie.org.uk Fri Aug 23 17:03:11 2024 From: paul at boddie.org.uk (Paul Boddie) Date: Fri, 23 Aug 2024 17:03:11 +0200 Subject: Showing signatures for exported/unimported keys using the Python GPGME bindings In-Reply-To: <87y14nbqv2.fsf@jacob.g10code.de> References: <3305442.ImKIP6uL9k@jason> <87y14nbqv2.fsf@jacob.g10code.de> Message-ID: <2734939.Fbvv65RQBL@jason> On Friday, 23 August 2024 10:11:45 CEST Werner Koch wrote: > > you might have noticed that we don't have a real maintainer for the > Python bindings anymore. The last maintainer did a lot on the > documentation front but less on the actual inner workings. Thanks for the reply! I didn't notice, unfortunately. I did find a discussion from a few years back where two competing sets of bindings were discussed, one using SWIG and one being constructed using the Python C API directly: https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031156.html > Instead of having used the convient SWIG based bindings we should have > done a manual binding to make sure that we have a stable API (and less > compiler warning ;-). It is more work of course but counting in all the > problems and the endless hours of fixing stuff this would have been > better in the end. I haven't done library binding work for Python in many years, so I can't comment on whether SWIG is the most appropriate tool. I suppose there is always the hope that a tool can automate the wrapping of the underlying library entirely, even if the result is still fairly low-level. I would have to reacquaint myself with the current selection of tools to see if that ever became remotely feasible. Many years ago, I made a high-level library for libxml2 based on the low-level Python bindings generated by the tool and resources in that library's own repository. So, I recognise that starting with low-level bindings and making higher-level bindings in a layered approach is entirely satisfactory. Others chose to use Pyrex/Cython to wrap libxml2 and to hide the underlying C library, but browsing their code suggests that this is also quite an intensive job: https://github.com/lxml/lxml/tree/master/src/lxml There may be benefits in using Cython instead of the Python C API directly, however. > > P.S. Some kind of quick reference mapping gpg operations to the API would > > be rather helpful. > The original SWIG idea was that there is no need for a separate > documentation. The higher level and more pythonese API was added latter > and is indeed not comprehensive. I didn't find any documentation for the higher-level bindings as provided, although I did find documentation for previous incarnations of the bindings online. For example: https://pygpgme.readthedocs.io/en/latest/ > It might be important for your considerations that we plan to split off > the language bindings into separate repos and tarballs. The main driver > for this is that the Qt folks prefer to use cmake and having both build > systems (cmake and autotools) is not easy for the maintainers. The > Python bindings will thus also be split into a separate library and it > will allow to have a maintainer who does not need to follow the gpgme > development all the day but instead rely on the stable GPGME API. > > See https://dev.gnupg.org/T7262 That seems like a reasonable approach, given the strong preferences people have for (and against) various build systems, plus the nightmare of having to integrate them within a common framework. However, in the specific case involving the lack of signatures for keys that are not resident in a keychain, I see that the behaviour is explained by code in the GPGME library itself. Looking at src/keylist.c, there are three functions, each calling some underlying function: gpgme_op_keylist_start -> _gpgme_engine_op_keylist gpgme_op_keylist_ext_start -> _gpgme_engine_op_keylist_ext gpgme_op_keylist_from_data_start -> _gpgme_engine_op_keylist_data These are described in the documentation, of course: https://www.gnupg.org/documentation/manuals/gpgme/Listing-Keys.html However, I see that the data-related function does not propagate keylist_mode from the context to the underlying function. In src/engine.c, the _gpgme_engine_op_keylist_data function invokes the appropriate engine operation without the mode. And in src/engine-gpg.c, which is the only engine implementing the keylist_data operation, I see that the gpg_keylist_data function does not support the mode and therefore cannot introduce --with-sig-list to the command options. In contrast, the other keylist operations employ the gpg_keylist_build_options function to convert the mode to appropriate command options, although I see that --with-sig-check, not --with-sig-list, is actually introduced if GPGME_KEYLIST_MODE_SIGS is specified. So, I think I am mostly left wondering whether this treatment or lack of treatment of the mode was intentional in GPGME for keylist_data, or whether it was an oversight that can be remedied. Paul From paul at boddie.org.uk Fri Aug 23 18:24:46 2024 From: paul at boddie.org.uk (Paul Boddie) Date: Fri, 23 Aug 2024 18:24:46 +0200 Subject: Showing signatures for exported/unimported keys using the Python GPGME bindings In-Reply-To: <2734939.Fbvv65RQBL@jason> References: <3305442.ImKIP6uL9k@jason> <87y14nbqv2.fsf@jacob.g10code.de> <2734939.Fbvv65RQBL@jason> Message-ID: <1872408.TuDfs0ZVrR@jason> On Friday, 23 August 2024 17:03:11 CEST Paul Boddie via Gnupg-devel wrote: > > So, I think I am mostly left wondering whether this treatment or lack of > treatment of the mode was intentional in GPGME for keylist_data, or whether > it was an oversight that can be remedied. Reviewing the sources in the gpgme repository, I see that _gpgme_engine_op_keylist_data does propagate the mode through to the keylist_data operation, and that gpg_keylist_data does use the mode to introduce --with-sig-check into the command invocation. These changes apparently fixed GPG bug #5438. So, the problem for me, at least, was the use of an older version of the library on my system - 1.14 - whereas the bug seems to have been fixed for version 1.18 and later: https://dev.gnupg.org/rMb2a2158384a9f048ff61ee0cebef8346055f0454 Sorry for the noise on this topic! Paul