[bug #65844] 4 test files abort on some architectures

Update of bug #65844 (group gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks ... I had already fixed three of those files when correcting the non-portable code in them

[bug #64983] PDF generation fails with texinfo/7.1

Update of bug #64983 (project gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks very much ... I applied your patch

[bug #64492] HTMLLinker.1: warnings with groff/1.23.0

Update of bug #64492 (project gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #1: Committed ... thanks. ___ Reply to

[bug #64493] Spelling errors in gdnc.m and gspath.1

Update of bug #64493 (project gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #1: Committed, thanks. ___ Reply to this

Re: Object creation error

> NSArray *justSaySay = [NSArray arrayWithObjects: > @"there's NOBODY know CHINA than me", > @"there's NOBODY know AMERICAN than me", > @"there's ANYBODY know GNUSTEP than me" > ]; This will often crash, so it is probably the cause of your problem. The +arrayQWithObjects: method requires that

[bug #63408] Support building with C99 compilers

Update of bug #63408 (project gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #1: The patch looks good and works for me ... applied to trunk. Thanks.

Re: gnustep-make doesn't support install software in different prefix

> On 22 Sep 2022, at 14:22, Zhu Zihao wrote: > > Current gnustep-make cannot handle the situation well if gnustep-make, > gnustep-base etc. were installed in different install prefix, which is > very common in Nix or Guix package manager. > > While installing gnustep-make, many variable like

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Update of bug #60952 (project gnustep): Open/Closed: In Test => Closed ___ Follow-up Comment #28: Changes merged into trunk. ___ Reply

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #27, bug #60952 (project gnustep): I've been away for a week (while other developers have been looking at the code and making suggestions to improve it). I expect we can merge it soon. ___ Reply to this item at:

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #23, bug #60952 (project gnustep): Thanks ... I made that modification to have 2000 slots available, and updated the tests. I also made a lot of simplifications to tzdb.h (removing unnecessary defines and includes etc) and made various portability changes (to make the code run

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #18, bug #60952 (project gnustep): I restructured the code changes, to retain the existing behavior for absolute time zones, and to fix some memory issues and remove unused code etc while getting the code to work on my primary dev system (CentOS). I noticed that

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #16, bug #60952 (project gnustep): I was looking at building (on GNU/Linux), but the code currently doesn't compile due to the use of a few undeclared macros in tzdb.c ___ Reply to this item at:

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #13, bug #60952 (project gnustep): Thanks for the new changes. For clarity, I would prefer all the public domain code to be in one file: nothing other than NSTimeZone.m will include tzdb_private.h so it would be find to put the public domain implementation there after the

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #11, bug #60952 (project gnustep): Thanks for looking at this. > it is tempting to toss the part of NSTimeZone that deals with transitions There is no problem throwing away old code as long as the new code does the job as well or better. However, the more that's changed, the

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #9, bug #60952 (project gnustep): > adding a wrapper function around chop() calls to check is when is after the last transition, > and on in this case give the answer based on the TZstring. I think this is the best approach since the timeZoneDetailForDate method is actually

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #8, bug #60952 (project gnustep): > but I note this bug: Either the value of version is 1 (the value it's initialised to), or the version is not 1 (and is set to header->tzh_version[0]) > if (1 == version) > That will always be false. No, that will be false only if it's a

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #5, bug #60952 (project gnustep): I think using public domain code is fine, as long as we include comments around it to make it clear that it *is* public domain (and where it came from). ___ Reply to this item at:

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Follow-up Comment #3, bug #60952 (project gnustep): Unfortunately, we don't have existing code to parse/implement the tzstring extension; that would need to be written from scratch. ___ Reply to this item at:

[bug #60952] NSTimeZone fail to deal with tzfile v2+

Update of bug #60952 (project gnustep): Status:None => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #1: Thanks very much

[bug #30086] defaults write doesn't support -dict-add, -array-add

Update of bug #30086 (project gnustep): Item Group: Bug => Change Request ___ Follow-up Comment #1: I don't think this request makes much sense on its own. The GNUstep defaults command was a

[bug #52483] GNUstep Make should honor @setfilename in .texi documents

Update of bug #52483 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: I applied the

[bug #58550] WebServer - Deadlock due to missing socketAddress

Update of bug #58550 (project gnustep): Open/Closed:Open => Closed ___ Reply to this item at: ___

[bug #59204] NSOperationQueue leak

Follow-up Comment #14, bug #59204 (project gnustep): I changed the definition of the macros in trunk (and added some comments). I do worry that there might be code that's broken by the behavior change though (I found/fixed one place). ___

[bug #59204] NSOperationQueue leak

Follow-up Comment #13, bug #59204 (project gnustep): I think we all agree that the loop in the macros is more trouble than it's worth, and we should change it. > Since you often want to wrap the body of a loop in an > autorelease pool, hijacking break & continue is > particularly dangerous.

[bug #59204] NSOperationQueue leak

Follow-up Comment #9, bug #59204 (project gnustep): I altered the retain/release change. The ENTER_POOL/LEAVE_POOL macros are presumably intended to marry the original retain/release mechanism with ARC semantics, and don't really work. I wonder if they are perhaps more of a danger than an

[bug #59204] NSOperationQueue leak

Update of bug #59204 (project gnustep): Open/Closed:Open => Analyzed ___ Follow-up Comment #6: Having investigated, I think your problem is not a leak, but one of timing. Your testcase

[bug #59204] NSOperationQueue leak

Follow-up Comment #5, bug #59204 (project gnustep): Thanks ... given the comment of the commit, it looks like this was an entirely accidental change. ___ Reply to this item at:

[bug #58550] WebServer - Deadlock due to missing socketAddress

Follow-up Comment #2, bug #58550 (project gnustep): Actually, it looks like it was already fixed long ago: time to make a release perhaps. However, the current code, while adding @"unknown" to the counted set (and thus avoiding the exception and locking issue), is removing nil at the end of the

[bug #58550] WebServer - Deadlock due to missing socketAddress

Update of bug #58550 (project gnustep): Status:None => Confirmed ___ Follow-up Comment #1: Thanks ... clearly a bug ... I'll fix that now.

[bug #58546] GSTLS certificate expiration test always fails on 32-bit architectures

Follow-up Comment #5, bug #58546 (project gnustep): In practice, I don't see testing this on 32bit systems as a priority. If the tests pass on 64bit systems then the code is very unlikely to have been broken (and now that the world has moved to 64bit, it doesn't seem important to have a specific

[bug #58546] GSTLS certificate expiration test always fails on 32-bit architectures

Update of bug #58546 (project gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks for spotting that ... patch applied.

[bug #53338] base configure script does not detect nonfragile ABI correctly

Follow-up Comment #4, bug #53338 (project gnustep): > Except that ARC requires the -fobjc-nonfragile-abi flag. It doesn't on my systems (and shouldn't afaik with any version of clang). I expect the error you got is because you aren't specifying the correct runtime, not because you aren't

[bug #53338] base configure script does not detect nonfragile ABI correctly

Follow-up Comment #2, bug #53338 (project gnustep): Sorry I missed seeing the original bug report here. I think this is probably referencing some old version of GNUstep, because it's talking about '-fobjc-nonfragile-abi'. David said that option doesn't work properly in clang, so it has been

Re: gnustep base test failure

> On 15 Feb 2018, at 12:27, Yavor Doganov <ya...@gnu.org> wrote: > > В Thu, 15 Feb 2018 08:46:40 +, Richard Frith-Macdonald написа: > >> I have changed the testcase in git to use a fixed negative currency >> format, rather than the one ICU supplies for

[bug #53035] NSNumberFormatter test failure with ICU 60.2

Update of bug #53035 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Sorry I missed

Re: gnustep base test failure

> On 14 Feb 2018, at 02:28, thomas kaeding wrote: > > One test failed (-ve number format). > > Tests/test.log attached as "check.log" > > gnustep-base-1.25.0 > gnustep-make-2.7.0 > GNU/linux with glibc 2.26 and kernel 4.14.2 and GCC 7.3.0 > > I did NOT subscribe

[bug #53080] NSPortMessage msgid is ignored when sending the message

Update of bug #53080 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks a lot ...

[bug #52879] 1.25.1 testsuite failures

Update of bug #52879 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks a lot. I

[bug #52778] pkg-config usage broken in cross-compilation mode

Update of bug #52778 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks a lot, I

[bug #52518] [GWorkspace] Unnecessarily complex build system

Update of bug #52518 (project gnustep): Category: Base/Foundation => Application ___ Reply to this item at: ___

[bug #52518] [GWorkspace] Unnecessarily complex build system

Update of bug #52518 (project gnustep): Category: Application => Base/Foundation ___ Reply to this item at: ___

[bug #51592] -[NSFileManager copyItemAtPath:toPath:error:] should not raise exceptions

Update of bug #51592 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Applied Gtraham's

[bug #50895] Change to size of NSComparisonResult breaks custom sort from 1.24.8 to 1.24.9

Update of bug #50895 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: You are right,

[bug #47618] NSPredicate: SELF implemented incorrectly

Update of bug #47618 (project gnustep): Status:None => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #1: While I'm not very

[bug #49021] NSTask can deliver NSTaskDidTerminateNotification on wrong thread

Update of bug #49021 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks ...

[bug #32876] GNUstep-base/-gui/-back should support building outside of the source directory

Follow-up Comment #1, bug #32876 (project gnustep): This sounds nice to me. Assuming that building in the source tree with GNUSTEP_BUILD_DIR=build defined already works, couldn't this be implemented by: 1. modifying configure.ac in some way so that the configure script was able to recognised

[bug #29730] Build attempt when typing 'make distclean' twice

Update of bug #29730 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #4: I checked .. make

[bug #34445] gnustep-make doesn't merge XXXInfo.plist items if the file resides in a subdir

Update of bug #34445 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing because

[bug #34838] can't localize resources residing on subdirectories

Update of bug #34838 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Documentation in

[bug #42778] Frameworks with different SONAME cannot coexist

Update of bug #42778 (project gnustep): Status:None => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #4: It seems Niels

[bug #50751] non-fragile abi compiler flag was incorrectly removed from common.make

Update of bug #50751 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks very much

[bug #35671] Wrong error from -[NSFileManager createDirectoryAtPath:...]

Update of bug #35671 (project gnustep): Category: Makefiles => Base/Foundation ___ Reply to this item at: ___

[bug #35671] Wrong error from -[NSFileManager createDirectoryAtPath:...]

Update of bug #35671 (project gnustep): Category: Base/Foundation => Makefiles ___ Reply to this item at: ___

Re: Dear GNUStep

> On 20 Feb 2017, at 06:31, 김정수 wrote: > > Hi. I am Korean iOS developer who have studied GNUStep. > > This is not a bug just question. please give me a light... > > > > when we initialize object in Objective-C, we usually write like this. > > > [NSObject alloc]. so

[bug #50031] libgnustep-base calls exit()

Update of bug #50031 (project gnustep): Status:None => Wont Fix Open/Closed:Open => Declined ___ Follow-up Comment #1: I have reviewed

[bug #50032] Use of gethostbyname()

Update of bug #50032 (project gnustep): Category:None => Base/Foundation Status:None => Fixed Open/Closed:Open => In Test

[bug #48179] GSRegisterCurrentThread should send NSWillBecomeMultiThreadedNotification

Update of bug #48179 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #3: Ap[plied, thanks.

[bug #47926] Poor performance in NSOperationQueue

Update of bug #47926 (project gnustep): Status: Need Info => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #3: I was hoping for a

[bug #48348] gnustep-config doesn't do what I want

Update of bug #48348 (project gnustep): Summary: gnustep-config output is unusable => gnustep-config doesn't do what I want ___ Follow-up Comment #1: gnustep-config was written as a quick solution to provide an easy way

[bug #47619] NSPredicate: aggregate function expressions implemented incorrectly

Follow-up Comment #3, bug #47619 (project gnustep): Thanks Niels ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.org/

[bug #47619] NSPredicate: aggregate function expressions implemented incorrectly

Update of bug #47619 (project gnustep): Status:None => Ready For Test Open/Closed:Open => In Test ___ Follow-up Comment #1: I never use

[bug #47661] regression in -[NSCalendarDate(OPENSTEP) dateByAddingYears:months:days:hours:minutes:seconds:]

Update of bug #47661 (project gnustep): Status: Need Info => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #3: OK, no problem.

[bug #47661] regression in -[NSCalendarDate(OPENSTEP) dateByAddingYears:months:days:hours:minutes:seconds:]

Update of bug #47661 (project gnustep): Status:None => Need Info ___ Follow-up Comment #1: I can't reproduce this ... I added a regression testcase in svn trunk (the last one in

[bug #47422] [NSCalendarDate descriptionWithCalendarFormat] hangs with some dates

Follow-up Comment #2, bug #47422 (project gnustep): PS thanks for the example/test app ... I adapted it a little and added it to the regression tests. ___ Reply to this item at:

[bug #47422] [NSCalendarDate descriptionWithCalendarFormat] hangs with some dates

Update of bug #47422 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks very much

[bug #43771] NSURLConnection making synchronous request can't authenticate using URL's credential

Update of bug #43771 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks, patch

[bug #45286] -[NSString initWithContentsOfFile:encoding:error:] can return nil without updating error variable

Update of bug #45286 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: In svn

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

Follow-up Comment #4, bug #46418 (project gnustep): Thanks very much for that ... the testcases pass on my CentOS-7 system. But ... the second one doesn't pass in OSX-10.11.3 :-( ___ Reply to this item at:

[bug #46418] NSPredicate is missing a predicateWithBlock implementation

Update of bug #46418 (project gnustep): Severity: 3 - Normal => 2 - Minor Item Group:None => Change Request ___ Follow-up Comment #1: Anyone want to

[bug #45239] [base] implement NSData base64EncodedStringWithOptions

Update of bug #45239 (project gnustep): Status:None => Fixed Assigned to:rmottola => None Open/Closed:Open => Closed

[bug #37372] libTidy-related functionality is missing from NSXML class suite

Update of bug #37372 (project gnustep): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #3: It seems nobody

[bug #34692] if multiple libobjc's exist, the use of AC_CHECK_FUNCS for checking functions in libobjc can give wrong results

Update of bug #34692 (project gnustep): Status:None => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #4: Closing as problem

[bug #47178] JDBC backend in SQLClient does not compile

Update of bug #47178 (project gnustep): Status:None => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #1: Ah ... never

[bug #46956] Thread safety issues in NSUserDefaults.m cause unwarranted exceptions to be raised

Update of bug #46956 (project gnustep): Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks very much. I applied your patch, then found/fixed a memory leak, and then ended up doing

Re: msys2 patches

On 16 Aug 2015, at 12:15, Seong Gu Lee sgle...@gmail.com wrote: Dear gnustep developers, It is first time for me to submit something here. msys2 is more convinient and updated than msys, so I tried to build windows version of gnustep with it. Some build tweaks are need to

[bug #45240] [base] implement NSData initWithBase64EncodedString

Update of bug #45240 (project gnustep): Assigned to:None = CaS ___ Reply to this item at: http://savannah.gnu.org/bugs/?45240 ___

[bug #45081] gui and back do not pick up compiler setting

Follow-up Comment #7, bug #45081 (project gnustep): I don't agree with that argument, but even if I did, it still has nothing to do with *this* issue. This issue is about having autoconf (ie the configure script) default to using the same compiler that you use when you build. It makes little

[bug #45081] gui and back do not pick up compiler setting

Follow-up Comment #5, bug #45081 (project gnustep): it enforced an installation process of the form gnustep-make - libobjc - gnustep-make - gnustep-base The gnustep-make - libobjc - gnustep-make sequence before configuring base is about making sure base is configured with the version of

[bug #45081] gui and back do not pick up compiler setting

Follow-up Comment #3, bug #45081 (project gnustep): I'm inclined to agree with Riccardo. I'd call it a request for improvement rather than a bug report though. What base does (I hope) when you run configure: 1. see if you explicitly specified what compiler to use 2. see what compiler

[bug #44240] NSThread leaks a run loop if NSFileHandle -finalize is called during deallocation

Update of bug #44240 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ... I fixed

Re: D'Oh!

On 21 Jan 2015, at 08:27, Douglas Havir ra...@nbs-inc.com wrote: Hello, I'm trying to install GNUstep on my RHEL6.5 system, and I ran into a problem with the ICU stuff. Apparently RHEL6.5 has ICU libraries installed by default, but, I'm running the x86_64 release, and the i686 libraries

Re: Error installing GNUstep Base on CentOS 7 server

On 20 Jan 2015, at 18:40, Bradley, Randy randy.brad...@ars.usda.gov wrote: GSXML.m: In function ‘-[GSXMLNode description]’: GSXML.m:983:38: error: dereferencing pointer to incomplete type string = UTF8StrLen(buf-buffer-content, buf-buffer-use); ^

[bug #43722] Parsing of strings to double can produce erroneous results

Update of bug #43722 (project gnustep): Status:None = Fixed Open/Closed:Open = In Test ___ Follow-up Comment #1: Thanks ... I have

[bug #43460] The class NSURLConnection needs to be tested more thoroughly

Update of bug #43460 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #4: Thanks very much ...

[bug #43641] GSServerStream doesn't support connections with SSL/TLS

Update of bug #43641 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ... I applied

[bug #43635] GSSocketOutputStream doesn't allow to postpone actual writing

Update of bug #43635 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: Thanks for that ...

[bug #43461] A memory leak in the -[NSURLProtocol stream:handleEvent:] in the case of HTTPS

Update of bug #43461 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #2: Thanks very much ..

[bug #43460] The class NSURLConnection needs to be tested more thoroughly

Follow-up Comment #1, bug #43460 (project gnustep): I really love this patch and the fact that you have produced testcases (they worked nicely for me and helped me check your NSURLProtocol patch). However, I'm afraid I don't think I can put it in the gnustep-base testsuite as it is. The reason

[bug #43348] [WebServer] Retain/release balance is broken for main IOThread

Update of bug #43348 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks very much ...

[bug #42640] GNUstep Make does not honor CFLAGS

Update of bug #42640 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ...

[bug #42648] Manual page for gnustep-tests

Update of bug #42648 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ... I applied

[bug #42781] In the case of HTTPS NSURLConnection doesn't report to it's delegate about a refused connection

Follow-up Comment #3, bug #42781 (project gnustep): I can't reproduce the problem but my best guess is that somehow ostream is being released, without clearing the ivar, before we can handle the event. If that's happening as a result of the event sent to istream immediately before, then retaining

[bug #42411] gdomap chroots to /tmp

Follow-up Comment #4, bug #42411 (project gnustep): I agree about 1 and 2 not being options. I don't agree with (3) since if we don't chroot then we have to assume that the executable has access to the whole filesystem ... and a chroot to /tmp can't possibly be less secure than that. Perhaps

[bug #42804] Dubious configure test for -fexec-charset

Follow-up Comment #2, bug #42804 (project gnustep): Thanks, has always been a pain ... and I didn't realise the gcc documentation was wrong. I think it would be good to remove it. ___ Reply to this item at:

[bug #42762] Large file support

Update of bug #42762 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ... that

[bug #42804] Dubious configure test for -fexec-charset

Update of bug #42804 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #3: OK ... make that

[bug #42781] In the case of HTTPS NSURLConnection doesn't report to it's delegate about a refused connection

Update of bug #42781 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ... that

[bug #41952] CentOS 5.x cannot install gnustep-base since r36344 (GSPrivateHash.m)

Update of bug #41952 (project gnustep): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #4: Tentatively closing

[bug #42717] Crash in -[NSBox(Private) calcSizesAllowingNegative:]

Follow-up Comment #12, bug #42717 (project gnustep): both being caused by a compiler that crashes when calling a method on nil that returns a structure type My understanding is that the behavior when calling a method expected to return a struct on a nil receiver is (and has always been)

[bug #42789] [SQLClient] Two versions of the library cannot coexist peacefully

Update of bug #42789 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks very much

  1   2   3   4   5   6   7   8   9   10   >