On Thu, 26 Mar 2020 at 05:51, Tim Rühsen wrote:
>
> We just need a mirror / fork on Github that we push to (sync) from time
> to time. If someone cares for the initial Travis and/or Cirrus setup
> with OSX / FreeBSD / Windows in mind, that would be great !
If such a fork/mirror is going to show u
On 9 April 2016 at 13:28, Paul Eggert wrote:
>
> I don't know about other C libraries, such as FreeBSD. It's possible that
> this implementation could be quite slow there, as you say.
C_LOCALE_MAYBE_EILSEQ is not set on FreeBSD.
On 4 December 2014 at 21:33, Daiki Ueno wrote:
> Ed Maste writes:
>
>> OK, I can reproduce it in a single-vCPU bhyve VM (the default is 2).
>> Do you mind checking if it's no longer reproducible in KVM with 2 or
>> more vCPUs?
>
> Thanks, it indeed seems to fi
On 4 December 2014 at 09:38, Ed Maste wrote:
>
> I've run it in a loop over 100 times and it is consistently 5 to 6
> seconds real time, 8 to 10 seconds sys.
>
> Perhaps there's some poor interaction with KVM involved? You mentioned
> you have more reports of this iss
On 3 December 2014 at 22:53, Daiki Ueno wrote:
>
> Actually, I haven't tried it on a bare metal, but on Assaf's freebsd10
> build-ready VM image:
>
> http://www.nongnu.org/pretest/downloads/
Oh, nice - I hadn't encountered that project before. It looks like a
great resource.
I downloaded the i
On 17 November 2014 at 05:34, Daiki Ueno wrote:
>
> As I'm getting more reports (perhaps) related to this, I've filed a bug
> at the FreeBSD bugzilla, with a reproducer written in plain pthreads:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195098
To clarify, does this issue seem to occur
On 25 April 2013 16:23, Paul Eggert wrote:
>
> I guess my test case wasn't a correct simplification of
> the gnulib test case. Could you please try the following
> test case instead? Thanks.
If my understanding is correct your replacement test case should still
pass even with the following chan
On 25 April 2013 22:39, Daiki Ueno wrote:
> I can still reproduce this on 9.1-RELEASE. Perhaps you are missing
> -pthread cflag when compiling?
Argh, you are right. What happened here is I built Paul's first test
using -lpthread, but it doesn't demonstrate the problem. Then I
somehow missed it
On 25 April 2013 16:23, Paul Eggert wrote:
> On 04/25/13 12:07, Ed Maste wrote:
>> I don't have a 9.1-RELEASE machine handy, but get the expected zero
>> return from this test program on the following FreeBSD versions (one
>> before and one after 9.1-RELEASE):
>
&g
Hmm, it seems this has been sitting in my drafts folder for quite some time.
> In that case perhaps we should leave the Gnulib test alone,
> and report a bug to the FreeBSD folks. Does the following
> simple test case elicit the bug for you? It should exit with status 0
> on any host conforming
On 2 October 2012 10:30, Ed Maste wrote:
> Thanks for the list - here's the current status, on 9.1 prerelease.
> It'll take a little while to fully analyze the remaining failures.
Here are some additional details and a re-sorted list.
*** Already fixed or in progress:
On 1 October 2012 22:50, Bruno Haible wrote:
> Hi Ed,
>
>> it looks like we're pretty close to having all of
>> the tests apply and pass on FreeBSD so I suspect I don't have many
>> more to find.
>
> Do you know what is the status of the following bugs in the newest
> FreeBSD release? Let me cite
On 1 October 2012 19:52, Bruno Haible wrote:
> Hi,
>
> Ed Maste wrote:
>> While investigating skipped tests on FreeBSD I found that test-poll
>> and test-select were skipped due to bind() returning EADDRINUSE. It
>> turns out that these tests call setsockopt(..., S
While investigating skipped tests on FreeBSD I found that test-poll
and test-select were skipped due to bind() returning EADDRINUSE. It
turns out that these tests call setsockopt(..., SO_REUSE... after
calling bind(), not before.
diff --git a/tests/test-poll.c b/tests/test-poll.c
index 7ba0280..6
On 1 October 2012 13:48, Jim Meyering wrote:
> Ed Maste wrote:
>
>> On 30 September 2012 17:39, Bruno Haible wrote:
>>> Jim Meyering wrote on 2012-08-28:
>>>> FAIL: test-localeconv (exit: 262)
>>>> =
>>
On 30 September 2012 17:39, Bruno Haible wrote:
> Jim Meyering wrote on 2012-08-28:
>> FAIL: test-localeconv (exit: 262)
>> =
>>
>> test-localeconv.c:41: assertion failed
>>
>> which corresponds to this line:
>>
>> $ cat -n tests/test-localeconv.c|gr
On 19 September 2012 10:11, Ed Maste wrote:
> On 18 September 2012 16:17, Ed Maste wrote:
>> This patch set adds an implementation of gl_locale_name_thread_unsafe
>> for FreeBSD. With this change all of the gnulib tests pass on FreeBSD
>> HEAD and the upcoming FreeBSD 9
On 18 September 2012 16:17, Ed Maste wrote:
> This patch set adds an implementation of gl_locale_name_thread_unsafe
> for FreeBSD. With this change all of the gnulib tests pass on FreeBSD
> HEAD and the upcoming FreeBSD 9.1 release.
>
> The second patch switches OS X to use this c
Signed-off-by: Ed Maste
---
This needs to be tested by someone with a Mac.
lib/localename.c | 129 +-
1 file changed, 2 insertions(+), 127 deletions(-)
diff --git a/lib/localename.c b/lib/localename.c
index 7d04742..697a3ba 100644
--- a/lib
Signed-off-by: Ed Maste
---
lib/localename.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/lib/localename.c b/lib/localename.c
index c6777de..7d04742 100644
--- a/lib/localename.c
+++ b/lib/localename.c
@@ -2616,8 +2616,34
does will need to test it.
Ed Maste (2):
Add FreeBSD locale name implementation.
Use FreeBSD implementation on OS X also.
lib/localename.c | 139 --
1 file changed, 20 insertions(+), 119 deletions(-)
--
1.7.10.3
On 13 September 2012 12:38, Paul Eggert wrote:
> Thanks. Do you happen to know whether (defined __APPLE__)
> implies (defined __FreeBSD__)? If so, the following patch
> should also work, and should be simpler. I'm asking because
> I don't use either OS X or FreeBSD, normally.
__FreeBSD__ isn't
The patch below adds an implementation of gl_locale_name_thread_unsafe
for FreeBSD. With this change all of the gllib tests will pass on
FreeBSD HEAD.
--- a/lib/localename.c
+++ b/lib/localename.c
@@ -2617,6 +2617,34 @@ gl_locale_name_thread_unsafe (int category, const char
*categoryname)
On 12 September 2012 19:57, Paul Eggert wrote:
> On 09/12/2012 11:29 AM, Ed Maste wrote:
>> 2605locale_t thread_locale = uselocale (NULL);
>
> I'm afraid you may need to be the guy to debug this.
> But if this is returning a value other than LC_GLOBAL_LOCALE
>
I've now fixed two of the four FreeBSD 9.1 failures in FreeBSD's libc.
One of the two remaining failures is:
feynman% gltests/test-localename
test-localename.c:183: assertion failed
zsh: abort (core dumped) gltests/test-localename
This appears to be missing functionality in gnulib for FreeBSD
(
On 12 September 2012 11:29, Eric Blake wrote:
> In POSIX, the wording "is not a directory" is true only if the file
> exists as some other type. But here, zzz does not even exist; hence,
> the ENOENT error takes precedence. This is a bug in the FreeBSD
> realpath() code, because they misinterpr
On 12 September 2012 10:44, Eric Blake wrote:
> On 09/12/2012 08:38 AM, Paul Eggert wrote:
>> On 09/12/2012 06:38 AM, Ed Maste wrote:
>>> Should ENOTDIR be a permissible errno for this test?
>>
>> I don't see why. It's not called out in the GNU document
I have four test failures when running the gnulib test suite (at 6418d7c961)
on FreeBSD, some of which are clear FreeBSD bugs. My test host is FreeBSD
9.1-PRERELEASE (r240164M).
One that isn't clear to me is:
test-canonicalize-lgpl.c:98: assertion failed
Abort trap (core dumped)
FAIL: test-canon
28 matches
Mail list logo
