GNU bug report logs -
#62420
29.0.60; fns-tests-collate-strings fails on Cygwin
Previous Next
Reported by: Ken Brown <kbrown <at> cornell.edu>
Date: Fri, 24 Mar 2023 14:59:02 UTC
Severity: normal
Found in version 29.0.60
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62420 in the body.
You can then email your comments to 62420 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Fri, 24 Mar 2023 14:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ken Brown <kbrown <at> cornell.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 24 Mar 2023 14:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The test in the subject fails on Cygwin as follows:
Test fns-tests-collate-strings condition:
(ert-test-failed
((should-error
(string-collate-equalp "xyzzy" "xyzzy" "en_DE.UTF-8"))
:form
(string-collate-equalp "xyzzy" "xyzzy" "en_DE.UTF-8")
:value t :fail-reason "did not signal an error"))
The reason is that en_DE.UTF-8 is actually a valid locale on Cygwin.
[Cygwin gets its locale information from Windows. The latter supports
the RFC 5646 locale "en-DE", which is called "English (Germany)" in the
"Region" settings.]
The following trivial patch fixes the problem:
--- a/test/src/fns-tests.el
+++ b/test/src/fns-tests.el
@@ -254,7 +254,7 @@ fns-tests-collate-strings
(should (string-collate-equalp "xyzzy" "XYZZY" nil t))
;; Locale must be valid.
- (should-error (string-collate-equalp "xyzzy" "xyzzy" "en_DE.UTF-8")))
+ (should-error (string-collate-equalp "xyzzy" "xyzzy" "en_XY.UTF-8")))
;; There must be a check for valid codepoints. (Check not
implemented yet)
; (should-error
Is this OK for the emacs-29 branch?
[Note: The test will still fail on current Cygwin after this patch; but
that's because of a bug in Cygwin, which has been fixed in the
development sources for Cygwin 3.5.]
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Sat, 25 Mar 2023 12:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 62420 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 24 Mar 2023 10:52:45 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
>
> The reason is that en_DE.UTF-8 is actually a valid locale on Cygwin.
> [Cygwin gets its locale information from Windows. The latter supports
> the RFC 5646 locale "en-DE", which is called "English (Germany)" in the
> "Region" settings.]
>
> The following trivial patch fixes the problem:
>
> --- a/test/src/fns-tests.el
> +++ b/test/src/fns-tests.el
> @@ -254,7 +254,7 @@ fns-tests-collate-strings
> (should (string-collate-equalp "xyzzy" "XYZZY" nil t))
> ;; Locale must be valid.
> - (should-error (string-collate-equalp "xyzzy" "xyzzy" "en_DE.UTF-8")))
> + (should-error (string-collate-equalp "xyzzy" "xyzzy" "en_XY.UTF-8")))
> ;; There must be a check for valid codepoints. (Check not
> implemented yet)
> ; (should-error
>
>
> Is this OK for the emacs-29 branch?
Yes, thanks.
> [Note: The test will still fail on current Cygwin after this patch; but
> that's because of a bug in Cygwin, which has been fixed in the
> development sources for Cygwin 3.5.]
Maybe mention this in comments? Bonus points for making it an
expected failure for Cygwin < 3.5, assuming the version of Cygwin
could be obtained by the test code.
Reply sent
to
Ken Brown <kbrown <at> cornell.edu>
:
You have taken responsibility.
(Sat, 25 Mar 2023 14:29:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ken Brown <kbrown <at> cornell.edu>
:
bug acknowledged by developer.
(Sat, 25 Mar 2023 14:29:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 62420-done <at> debbugs.gnu.org (full text, mbox):
On 3/25/2023 8:24 AM, Eli Zaretskii wrote:
>> Date: Fri, 24 Mar 2023 10:52:45 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> Is this OK for the emacs-29 branch?
>
> Yes, thanks.
>
>> [Note: The test will still fail on current Cygwin after this patch; but
>> that's because of a bug in Cygwin, which has been fixed in the
>> development sources for Cygwin 3.5.]
>
> Maybe mention this in comments?
Done.
> Bonus points for making it an
> expected failure for Cygwin < 3.5, assuming the version of Cygwin
> could be obtained by the test code.
I don't know how to get the version in Lisp. I only know how to get it
in C, using uname. If someone can tell me how to get it in Lisp, I'll
try to earn the bonus points.
Closing.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Sat, 25 Mar 2023 14:48:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 62420 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 25 Mar 2023 10:27:51 -0400
> Cc: 62420-done <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
>
> On 3/25/2023 8:24 AM, Eli Zaretskii wrote:
> >> Date: Fri, 24 Mar 2023 10:52:45 -0400
> >> From: Ken Brown <kbrown <at> cornell.edu>
> >> Is this OK for the emacs-29 branch?
> >
> > Yes, thanks.
> >
> >> [Note: The test will still fail on current Cygwin after this patch; but
> >> that's because of a bug in Cygwin, which has been fixed in the
> >> development sources for Cygwin 3.5.]
> >
> > Maybe mention this in comments?
>
> Done.
Thanks.
> > Bonus points for making it an
> > expected failure for Cygwin < 3.5, assuming the version of Cygwin
> > could be obtained by the test code.
>
> I don't know how to get the version in Lisp. I only know how to get it
> in C, using uname. If someone can tell me how to get it in Lisp, I'll
> try to earn the bonus points.
What's the value of operating-system-release return in a Cygwin build?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Sat, 25 Mar 2023 15:16:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 62420 <at> debbugs.gnu.org (full text, mbox):
On 3/25/2023 10:46 AM, Eli Zaretskii wrote:
>> Date: Sat, 25 Mar 2023 10:27:51 -0400
>> Cc: 62420-done <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> cornell.edu>
>> I don't know how to get the version in Lisp. I only know how to get it
>> in C, using uname. If someone can tell me how to get it in Lisp, I'll
>> try to earn the bonus points.
>
> What's the value of operating-system-release return in a Cygwin build?
Perfect! It's "3.4.6-1.x86_64". I should be able to use that.
Interestingly, that variable was made obsolete a couple years ago in
commit d88e12aa19c4.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Sat, 25 Mar 2023 15:50:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 62420 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 25 Mar 2023 11:14:57 -0400
> Cc: 62420 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
>
> > What's the value of operating-system-release return in a Cygwin build?
>
> Perfect! It's "3.4.6-1.x86_64". I should be able to use that.
> Interestingly, that variable was made obsolete a couple years ago in
> commit d88e12aa19c4.
We can un-obsolete it if Cygwin asks nicely ;-)
There's also the method used in report-emacs-bug--os-description,
maybe we could refactor it into a public function.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Sat, 25 Mar 2023 16:49:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 62420 <at> debbugs.gnu.org (full text, mbox):
On 3/25/2023 11:49 AM, Eli Zaretskii wrote:
>> Date: Sat, 25 Mar 2023 11:14:57 -0400
>> Cc: 62420 <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> cornell.edu>
>>
>>> What's the value of operating-system-release return in a Cygwin build?
>>
>> Perfect! It's "3.4.6-1.x86_64". I should be able to use that.
>> Interestingly, that variable was made obsolete a couple years ago in
>> commit d88e12aa19c4.
>
> We can un-obsolete it if Cygwin asks nicely ;-)
Thanks, but that's unnecessary. It turns out that the test succeeds on
the currently released Cygwin. The bug that caused it to fail was
introduced in the development sources for 3.5 and is now fixed there.
So there's no known Cygwin release in which it fails.
But I'm glad to know about operating-system-release anyway. Maybe it
will be useful some other time.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62420
; Package
emacs
.
(Sat, 25 Mar 2023 18:07:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 62420 <at> debbugs.gnu.org (full text, mbox):
On Sat, Mar 25, 2023 at 9:46 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> What's the value of operating-system-release return in a Cygwin build?
>
corwi <at> Avalon /cygdrive/c/Users/corwi
$ emacs --version; emacs -batch -eval '(message "%s" operating-system-release)'
GNU Emacs 26.3
[...]
3.0.7-338.x86_64
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 23 Apr 2023 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 21 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.