FreeBSD_HEAD-tests - Build #1678 - Still Unstable
FreeBSD_HEAD-tests - Build #1678 - Still Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1678/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1678/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1678/console
Change summaries:
No changes
The failed test cases:
5 tests failed.
FAILED: bin.sh.builtins.functional_test.case7
Error Message:
atf-check failed; see the output of the test for details
FAILED: bin.sh.builtins.functional_test.locale1
Error Message:
atf-check failed; see the output of the test for details
FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED:
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
[123,456,78.0625]<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
> On Nov 8, 2015, at 20:51, Shane Ambler wrote: ... > 4 seconds?? > There have been 4 leap seconds added this century. > Did 1.9 add timestamp corrections relating to leap seconds? > > Did the developer not use leapsecs when the svn server does? Alternatively, was this impacted by a change in recent change to timekeeping (ntpd, etc)? Thanks, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
On 08/11/2015 21:36, Ulrich Spörlein wrote: Here's the same commit, and the difference between 1.8 and 1.9: % git cat-file commit 803795d tree 7fc83aba022834da5c218114b09ad4640735bcc0 parent c96fb0418e545a569b5975b4d878a30a948c29d5 author olgeni 1437203525 + committer olgeni 1437203525 + Upgrade to version 0.4.1. % git cat-file commit 61ca43b tree 7fc83aba022834da5c218114b09ad4640735bcc0 parent c96fb0418e545a569b5975b4d878a30a948c29d5 author olgeni 1437203529 + committer olgeni 1437203529 + Upgrade to version 0.4.1. In case you don't see it, there's a 4s difference in the timestamps for authoring and committing. Here's the original: % svn log -vc392405 svn://svn.freebsd.org/ports r392405 | olgeni | 2015-07-18 09:12:05 +0200 (Sat, 18 Jul 2015) | 2 lines Changed paths: M /head/www/elixir-maru/Makefile M /head/www/elixir-maru/distinfo Upgrade to version 0.4.1. So yeah, svn 1.9 returned a timestamp that was off by 4s. WTF? 4 seconds?? There have been 4 leap seconds added this century. Did 1.9 add timestamp corrections relating to leap seconds? Did the developer not use leapsecs when the svn server does? -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09.11.2015 0:46, Baptiste Daroussin wrote: >> BTW, see other tests fails here in jenkins too, they looks >> related to locale changes. > > I will look into them. About that one, it looks like collate support is broken in regex: FAILED: bin.sh.builtins.functional_test.case7 All our collate files was in order A-Za-z but CLDR collate organized as aA<...>-zZ Since RE ranges should use collate (per POSIX), new a-z includes now every letter, small and big, excluding Z (for de_DE locale in the test). It means, case7 two tests (below) should succeed even with new collate, but both fails (second one includes various oO variants, with umlaut too). Our regex code have collate support for single byte locales, but it seems it is not in the working state now. unset LC_ALL LC_CTYPE=de_DE.ISO8859-1 export LC_CTYPE LC_COLLATE=de_DE.ISO8859-1 export LC_COLLATE c1=e # o umlaut c2=$(printf '\366') case $c1$c2 in [a-z][a-z]) ;; *) echo wrong at $LINENO ;; esac case $c1$c2 in [a-f][n-p]) ;; *) echo wrong at $LINENO ;; esac - -- http://ache.vniz.net/ -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJWQAw2AAoJEKUckv0MjfbKRA0H/3c2n0slDo78mnxUv+wi7LKU lppgVWkBitskMNq02OBaV4kOogbrwe5RAfhDqFhOIB4oISh/1qMZi2lCiSyx6wAY ZRqaJXefMxLm+oFA9RECiSUrwPaAAS71spCVDBzVDZoRbHobJCkmt9/DdgDBE3P4 lzTucr2XAhXTBBmHIQKDzKBfnm8Pi/r6H74K1UkthCRe0TP01aW8QnVuJYrzIYE1 hPv7kbdO62w7NxARRaQQkMediDh5odl3pcIbH16EexnaCOG6ouTnY4dcCMwDOcz+ 9IwBwh+Nn0ERICcHciYS9C5j+bSoP1BBAwwhYi2+kCitRGFOQ/U8PjYkBPbT0Xw= =y4/D -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r288669 breaks ports building with USE_GCC=yes
Hi Gerald; > Il giorno 08/nov/2015, alle ore 19:00, Gerald Pfeifer ha > scritto: > > On Tue, 13 Oct 2015, Justin Hibbits wrote: >> As Antoine mentioned, the problem is that lang/gcc does not have this >> patch. USE_GCC uses lang/gcc, not lang/gcc48. So lang/gcc needs to >> be updated. > > I have (finally) managed to steal the team, kicked off testing, > and plan on committing the patches already in lang/gcc48 also > to lang/gcc in the next 24 hours. > Great! We already worked around the issue by disabling stack-protector-strong for gcc48 though. What looks somewhat strange to me is that lang/gcc is an independent port when it should just be a link to the current gcc default. > Thanks for the report and suggestions! > BTW, perhaps it’s time to bump the default gcc to gcc49? ;). Regards, Pedro. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD_sparc64 - Build #1311 - Still Failing
> On Nov 7, 2015, at 10:39, Garrett Cooper wrote: > >> On Nov 7, 2015, at 06:18, Andriy Gapon wrote: >> >>> On 07/11/2015 10:00, jenkins-ad...@freebsd.org wrote: >>> In file included from >>> /builds/FreeBSD_HEAD_sparc64/gnu/lib/libstdc++/../../../contrib/gcc/debug.c:19: >>> /builds/FreeBSD_HEAD_sparc64/gnu/lib/libstdc++/../../../contrib/gcc/system.h:418: >>> error: conflicting types for 'strsignal' >>> /builds/FreeBSD_HEAD_sparc64/obj/sparc64.sparc64/builds/FreeBSD_HEAD_sparc64/tmp/usr/include/string.h:115: >>> error: previous declaration of 'strsignal' was here >> >> Has this been fixed? > > I don't think so.. Nope, still a problem. We have it defined in some of the config.h files — why isn’t it picking them up properly now? $ grep -r HAVE_STRSIGNAL gnu/ gnu/usr.bin/cc/libiberty/config.h:#define HAVE_STRSIGNAL 1 gnu/usr.bin/cc/cc_tools/auto-host.h:#define HAVE_STRSIGNAL 1 gnu/usr.bin/binutils/libiberty/config.h:#define HAVE_STRSIGNAL 1 $ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mtree patch for WITHOUT_LPR
> On Nov 8, 2015, at 17:04, Garance A Drosehn wrote: > > On 7 Nov 2015, at 6:08, Dmitry Morozovsky wrote: >> >> as you're still maintaining lpr, I'm passing this through you. >> >> If one build his server WITHOUT_LPR, there are constantly few directories >> that >> are created by make hierarchy and then reported my make check-old. >> >> Attached is a small patch against -current that should eliminate it (inspired >> by BSD.groff.mtree). >> >> Your thoughts? > > Thanks for checking with me. > > While I've done a lot with 'lpr', I have not done much of anything with > mtree files. > > After having read through the rest of this thread, I have the impression > that we're no longer interested in a separate mtree subfile for 'lpr'. > Instead we'll go with Brian's observation that: "if a directory is in the > dist mtrees, it should not be listed as an OLD_DIRS." > > Am I correct in thinking that? With OptionalObsoleteFiles.inc, yes. With ObsoleteFiles.inc, the directories should still be removed. Thanks! -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mtree patch for WITHOUT_LPR
On 7 Nov 2015, at 6:08, Dmitry Morozovsky wrote: as you're still maintaining lpr, I'm passing this through you. If one build his server WITHOUT_LPR, there are constantly few directories that are created by make hierarchy and then reported my make check-old. Attached is a small patch against -current that should eliminate it (inspired by BSD.groff.mtree). Your thoughts? Thanks for checking with me. While I've done a lot with 'lpr', I have not done much of anything with mtree files. After having read through the rest of this thread, I have the impression that we're no longer interested in a separate mtree subfile for 'lpr'. Instead we'll go with Brian's observation that: "if a directory is in the dist mtrees, it should not be listed as an OLD_DIRS." Am I correct in thinking that? -- Garance Alistair Drosehn= dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD-tests - Build #1677 - Still Unstable
FreeBSD_HEAD-tests - Build #1677 - Still Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1677/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1677/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1677/console
Change summaries:
No changes
The failed test cases:
5 tests failed.
FAILED: bin.sh.builtins.functional_test.case7
Error Message:
atf-check failed; see the output of the test for details
FAILED: bin.sh.builtins.functional_test.locale1
Error Message:
atf-check failed; see the output of the test for details
FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED:
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
[123,456,78.0625]<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r288669 breaks ports building with USE_GCC=yes
On Tue, 13 Oct 2015, Justin Hibbits wrote: > As Antoine mentioned, the problem is that lang/gcc does not have this > patch. USE_GCC uses lang/gcc, not lang/gcc48. So lang/gcc needs to > be updated. I have (finally) managed to steal the team, kicked off testing, and plan on committing the patches already in lang/gcc48 also to lang/gcc in the next 24 hours. Thanks for the report and suggestions! Gerald ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld broken
On Sun, Nov 08, 2015 at 11:43:16AM -0800, David Wolfskill wrote: > On Sun, Nov 08, 2015 at 10:28:17AM -0800, Steve Kargl wrote: > > ... > > Back to trying to build freebsd. I have discovered that > > 'make buildworld' is simply broken if one attempts to use > > a symlink for /usr/obj. At least doing doing > > > > % rm -rf /usr/obj > > % ln -s /mnt/obj /usr/obj > > % cd /usr/src > > % nice make -j2 buildworld > > > > with /mnt a UFS2 file system on a USB2 disk yields errors of the > > above form. > > My laptop -- where I build stable/10 & head daily -- is set up so that: > > g1-252(10.2-S)[1] ls -lT /usr/obj > lrwxr-xr-x 1 root wheel 14 Jul 19 06:39:21 2015 /usr/obj -> /common/S1/obj > g1-252(10.2-S)[2] > > In this case, /tmp is tmpfs and all others are UFS2+SU. > > > If one does > > > > % rm -rf /usr/obj > > % setenv OBJDIR /mnt/obj > > % cd /usr/src > > % nice make -j2 buildworld > > > > works. So, it appears soemthing inside the make infrastructure cannot > > follow symlinks. This used to work. > > In such cases, my first suspect is (ab)use of realpath. > Thanks for the response. Perhaps, you're right. I have no problem with changing my build methods to use OBJDIR instead of a symlink. Hopefully, whatever is broken in the make infrastructure won't have problems with the symlink from /usr/ports/distfiles to /mnt/distfiles. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
> On Nov 8, 2015, at 14:09, Andrey Chernov wrote:
>
> Signed PGP part
> On 09.11.2015 0:46, Baptiste Daroussin wrote:
> >> Error Message:
> > printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625],
> > expected [123,456,78.0625]<>
>
> Looks like numericdef "grouping" handling problem...
> >>>
> >>> Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig
> >>> into it
> >>
> >> Old FreeBSD hi_IN.ISCII-DEV locale uses 2;3 grouping. New
> >> hi_IN.UTF-8 locale use 3;2 grouping instead. I don't know what is
> >> right in India.
> >
> > About the locales we take the rules from http://cldr.unicode.org/
> > if there are issues they should be reported there! (note that those
> > rules are also used by the ICU project for examples.
>
> According to https://en.wikipedia.org/wiki/Indian_numbering_system
> cldr is right, old FreeBSD and the test is wrong here.
Ok. If no one else beats me to this, I’ll fix the test sometime later on today
after I upgrade my VM.
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09.11.2015 0:46, Baptiste Daroussin wrote:
>> Error Message:
> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625],
> expected [123,456,78.0625]<>
Looks like numericdef "grouping" handling problem...
>>>
>>> Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig
>>> into it
>>
>> Old FreeBSD hi_IN.ISCII-DEV locale uses 2;3 grouping. New
>> hi_IN.UTF-8 locale use 3;2 grouping instead. I don't know what is
>> right in India.
>
> About the locales we take the rules from http://cldr.unicode.org/
> if there are issues they should be reported there! (note that those
> rules are also used by the ICU project for examples.
According to https://en.wikipedia.org/wiki/Indian_numbering_system
cldr is right, old FreeBSD and the test is wrong here.
- --
http://ache.vniz.net/
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJWP8gCAAoJEKUckv0MjfbKnXsIAIXvlY48Op9uTRd+k7KUe6s+
Npmtn+b0AN+3tA47DvhPPAyF6hIyBXaEN93U60We5jv99U+nO4Tq6pXVFfp8nh67
+H43shwt/wckcf4cOGvn+koPYNqlU9CYvbxfV8hlWGZ56YZehKlxWJRxD7iITRva
3qqYvVdbf6aSGVzBzuoXgzpMYD4z1/eT4WzYyE1/aCy5KB1UGKHi0/XeLwHCSx7G
p8k+lhC10OJt+ueDIVK6X53wvQK1F1aJMhPEP1gW5CSN+3c2eTqz2zIKQVAGLQmm
xo0aHaHpjyv1aKg1XHxglrpc7N/z0waSpDm9LVbwWm6Xq2g6288nmlV0oQkJjvg=
=H4nd
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
> On Nov 8, 2015, at 13:49, Baptiste Daroussin wrote:
>
> On Sun, Nov 08, 2015 at 01:27:28PM -0800, NGie Cooper wrote:
>>
>>> On Nov 8, 2015, at 13:08, Baptiste Daroussin wrote:
>>>
>>> On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote:
On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
> FreeBSD_HEAD-tests - Build #1675 - Unstable:
>
> Build information:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/
> Full change log:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
> Full build log:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
...
> FAILED:
> lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
>
> Error Message:
> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
> [123,456,78.0625]<>
Looks like numericdef "grouping" handling problem...
>>>
>>> Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig into it
>>
>> Sidenote: all of these tests work on amd64@r289441 (which is 2 weeks/1000
>> revs behind, I know…). I intentionally integrated in a bunch of tests from
>> tools/regression/lib/libc to catch any potential regressions that were
>> checked in recently (especially in the locale space).
>> Thanks,
>
> I would have appreciated a mail about this when I issued the call for
> testing...
I wish I had remembered :/. Many people overlook the test cases in
tools/regression; that’s why I’m working hard to integrate them in to the test
suite — so they’re used again [on a regular basis].
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
On Sun, Nov 08, 2015 at 01:27:28PM -0800, NGie Cooper wrote:
>
> > On Nov 8, 2015, at 13:08, Baptiste Daroussin wrote:
> >
> > On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote:
> >> On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
> >>> FreeBSD_HEAD-tests - Build #1675 - Unstable:
> >>>
> >>> Build information:
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/
> >>> Full change log:
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
> >>> Full build log:
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
> >> ...
> >>> FAILED:
> >>> lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
> >>>
> >>> Error Message:
> >>> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
> >>> [123,456,78.0625]<>
> >>
> >> Looks like numericdef "grouping" handling problem...
> >
> > Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig into it
>
> Sidenote: all of these tests work on amd64@r289441 (which is 2 weeks/1000
> revs behind, I know…). I intentionally integrated in a bunch of tests from
> tools/regression/lib/libc to catch any potential regressions that were
> checked in recently (especially in the locale space).
> Thanks,
I would have appreciated a mail about this when I issued the call for testing...
Bapt
signature.asc
Description: PGP signature
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
On Mon, Nov 09, 2015 at 12:27:34AM +0300, Andrey Chernov wrote:
> On 09.11.2015 0:08, Baptiste Daroussin wrote:
> > On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote:
> >> On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
> >>> FreeBSD_HEAD-tests - Build #1675 - Unstable:
> >>>
> >>> Build information:
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/ Full
> >>> change log:
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
> >>>
> >>>
> Full build log:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
> >> ...
> >>> FAILED:
> >>> lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
> >>>
> >>>
> >>>
> Error Message:
> >>> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
> >>> [123,456,78.0625]<>
> >>
> >> Looks like numericdef "grouping" handling problem...
> >
> > Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig into
> > it
>
> Old FreeBSD hi_IN.ISCII-DEV locale uses 2;3 grouping. New hi_IN.UTF-8
> locale use 3;2 grouping instead. I don't know what is right in India.
About the locales we take the rules from http://cldr.unicode.org/ if there are
issues they should be reported there! (note that those rules are also used by
the ICU project for examples.
>
> BTW, see other tests fails here in jenkins too, they looks related to
> locale changes.
I will look into them.
Bapt
signature.asc
Description: PGP signature
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
On 09.11.2015 0:08, Baptiste Daroussin wrote:
> On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote:
>> On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
>>> FreeBSD_HEAD-tests - Build #1675 - Unstable:
>>>
>>> Build information:
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/ Full
>>> change log:
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
>>>
>>>
Full build log:
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
>> ...
>>> FAILED:
>>> lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
>>>
>>>
>>>
Error Message:
>>> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
>>> [123,456,78.0625]<>
>>
>> Looks like numericdef "grouping" handling problem...
>
> Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig into
> it
Old FreeBSD hi_IN.ISCII-DEV locale uses 2;3 grouping. New hi_IN.UTF-8
locale use 3;2 grouping instead. I don't know what is right in India.
BTW, see other tests fails here in jenkins too, they looks related to
locale changes.
--
http://ache.vniz.net/
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
> On Nov 8, 2015, at 13:08, Baptiste Daroussin wrote:
>
> On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote:
>> On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
>>> FreeBSD_HEAD-tests - Build #1675 - Unstable:
>>>
>>> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/
>>> Full change log:
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
>>> Full build log:
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
>> ...
>>> FAILED:
>>> lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
>>>
>>> Error Message:
>>> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
>>> [123,456,78.0625]<>
>>
>> Looks like numericdef "grouping" handling problem...
>
> Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig into it
Sidenote: all of these tests work on amd64@r289441 (which is 2 weeks/1000 revs
behind, I know…). I intentionally integrated in a bunch of tests from
tools/regression/lib/libc to catch any potential regressions that were checked
in recently (especially in the locale space).
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD-tests - Build #1676 - Still Unstable
FreeBSD_HEAD-tests - Build #1676 - Still Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1676/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1676/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1676/console
Change summaries:
No changes
The failed test cases:
6 tests failed.
FAILED: bin.sh.builtins.functional_test.case7
Error Message:
atf-check failed; see the output of the test for details
FAILED: bin.sh.builtins.functional_test.locale1
Error Message:
atf-check failed; see the output of the test for details
FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.stdio.print_positional_test.__test_cases_list__
Error Message:
Tester did not exit cleanly: kyua-atf-tester: Invalid test cases list header
'1..4'
FAILED:
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
[123,456,78.0625]<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
On Sun, Nov 08, 2015 at 11:10:58PM +0300, Andrey Chernov wrote:
> On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
> > FreeBSD_HEAD-tests - Build #1675 - Unstable:
> >
> > Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/
> > Full change log:
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
> > Full build log:
> > https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
> ...
> > FAILED:
> > lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
> >
> > Error Message:
> > printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
> > [123,456,78.0625]<>
>
> Looks like numericdef "grouping" handling problem...
Seems like the issue is only with hi_IN.ISCII-DEV, I'll dig into it
Best regards,
Bapt
signature.asc
Description: PGP signature
Re: FreeBSD_HEAD-tests - Build #1675 - Unstable
On 08.11.2015 22:08, jenkins-ad...@freebsd.org wrote:
> FreeBSD_HEAD-tests - Build #1675 - Unstable:
>
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/
> Full change log:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
> Full build log:
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
...
> FAILED:
> lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
>
> Error Message:
> printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
> [123,456,78.0625]<>
Looks like numericdef "grouping" handling problem...
--
http://ache.vniz.net/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
On Sun, Nov 8, 2015 at 12:06 PM, Ulrich Spörlein wrote: > 2015-11-08 11:32 GMT+01:00 Ulrich Spörlein : >> 2015-11-08 2:51 GMT+01:00 Alfred Perlstein : >>> Uli, >>> >>> One of the biggest concerns I've heard from folks using FreeBSD's git mirror >>> is that the hashes can change. >>> >>> I have a question about this. Is it possible to keep track of what the >>> "official" git mirror (on github) is doing and keep that as a log. Then >>> that log can be used to replay commits when there is a divergence problem. >>> >>> What I'm basically saying is that let's take this small example: >>> >>> importer is working fine @rev 1 >>> imports 1 >>> imports 10001 >>> imports 10002 >>> something happens to importer to give indeterminate shas. >>> imports 10003 - sha is "unstable" sha3 >>> imports 10004 - sha is "unstable" sha4 >>> imports 10005 - sha is "unstable" sha5 >>> imports 10006 - sha is "unstable" sha6 >>> importer is fixed >>> >>> >>> At this point normally we'd rewind the importer to 10002 and then force >>> update the affected branches. >>> >>> My question is... can the imports of 10003, 10004, 10005 and 10006 be put >>> into the importer such that any "mirror site" that re-does the import using >>> the most up to date importer will get the same shas. >>> >>> That would allow to proceed with 10007, etc without force pushing. >>> >>> This should be possible based on querying "git" for the meta data associated >>> with sha3..sha6 and then forcing those commits to have the same meta data. >>> >>> This would eliminate the concern about shas in the mirror changing that I've >>> heard. >> >> The goal of the conversion is that everyone can re-do the conversion >> in their basement and come up with the same history and checksums. >> This was not the case when I first started, as there was some >> non-deterministic hash structure being used in svn2git. This was fixed >> in the code and then all converter runs produced the very same >> results. >> >> The scenario that we have right now, is that one of the merge commits >> done about two weeks ago is being handled different by svn2git w/ svn >> v1.8 vs. svn v1.9 and I haven't investigated yet how the API's >> behavior changed to cause this. I'm afraid I also swapped out all my >> knowledge about svn2git internals and will have to redo this all from >> scratch :/ >> >> Your suggestion could only work, if we hard-code this svn revision >> special handling into svn2git, either in the code or by providing more >> mappings and rules to the process. svn2git should run hermetic and not >> poke at github's commits to see how things were handled in the past. >> It has to be self-sufficient and must not depend on github. >> >> This would also only work, if the "breakage" window was very small, >> but it is already about two weeks long and will surely increase till I >> find the proper fix. >> >> So, to take a stand here: this sort of kludge is unlikely to ever >> happen. Git commit hashes *might* change in the future. I really don't >> see how this is a big deal anyway. It happened once and I'm trying to >> have it never happen again. But why are people afraid of this >> happening? Every "official" git commit is tagged with a SVN revision >> and the contents of those revisions are obviously correct (just not >> the ancestry and the commit objects, possibly). So it would be easy to >> write a script that replays VendorA's git history and swaps out the >> new official commits for the old official commits. There would be no >> merge conflicts. >> >> I can see how this would be annoying if you have 100 developers and >> dozens of branches that are far from mainline FreeBSD. But I'm sure >> these companies that depend on git will come forward and donate some >> of their developer manpower to help me with keeping the converter >> stable/deterministic. Right? Right? :) :) >> >> Cheers, >> Uli > Hi Uli! I can not find your original svn2git repo in gitorius (https://gitorious.org/ is down) , could you please the source code somewhere to git-repo? For example github.com/freebsd/svn2git? > Quick update: doc is so far unaffected by svn 1.9, but for ports, the > drift happened as of Jul 18, so you'd need to special case a lot of > commits. > > Here's the same commit, and the difference between 1.8 and 1.9: > > % git cat-file commit 803795d > tree 7fc83aba022834da5c218114b09ad4640735bcc0 > parent c96fb0418e545a569b5975b4d878a30a948c29d5 > author olgeni 1437203525 + > committer olgeni 1437203525 + > > Upgrade to version 0.4.1. > % git cat-file commit 61ca43b > tree 7fc83aba022834da5c218114b09ad4640735bcc0 > parent c96fb0418e545a569b5975b4d878a30a948c29d5 > author olgeni 1437203529 + > committer olgeni 1437203529 + > > Upgrade to version 0.4.1. > > > In case you don't see it, there's a 4s difference in the timestamps > for authoring and committing. Here's the original: > > % svn log -vc392405 svn://svn.freebsd.org/ports > ---
Re: buildworld broken
On Sun, Nov 08, 2015 at 10:28:17AM -0800, Steve Kargl wrote: > ... > Back to trying to build freebsd. I have discovered that > 'make buildworld' is simply broken if one attempts to use > a symlink for /usr/obj. At least doing doing > > % rm -rf /usr/obj > % ln -s /mnt/obj /usr/obj > % cd /usr/src > % nice make -j2 buildworld > > with /mnt a UFS2 file system on a USB2 disk yields errors of the > above form. My laptop -- where I build stable/10 & head daily -- is set up so that: g1-252(10.2-S)[1] ls -lT /usr/obj lrwxr-xr-x 1 root wheel 14 Jul 19 06:39:21 2015 /usr/obj -> /common/S1/obj g1-252(10.2-S)[2] In this case, /tmp is tmpfs and all others are UFS2+SU. > If one does > > % rm -rf /usr/obj > % setenv OBJDIR /mnt/obj > % cd /usr/src > % nice make -j2 buildworld > > works. So, it appears soemthing inside the make infrastructure cannot > follow symlinks. This used to work. In such cases, my first suspect is (ab)use of realpath. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who would murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: buildworld broken
On Sun, Nov 01, 2015 at 11:19:09PM -0800, NGie Cooper wrote: > > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference to > > `PKCS7_dataInit' > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference to > > `PKCS7_dataDecode' > > /usr/obj/usr/src/tmp/usr/lib/libcrypto.so: undefined reference to > > `PKCS7_signatureVerify' > > Hi Steve, > What are your custom build options? Have you patched your copy of > FreeBSD? > Thanks! Back to trying to build freebsd. I have discovered that 'make buildworld' is simply broken if one attempts to use a symlink for /usr/obj. At least doing doing % rm -rf /usr/obj % ln -s /mnt/obj /usr/obj % cd /usr/src % nice make -j2 buildworld with /mnt a UFS2 file system on a USB2 disk yields errors of the above form. If one does % rm -rf /usr/obj % setenv OBJDIR /mnt/obj % cd /usr/src % nice make -j2 buildworld works. So, it appears soemthing inside the make infrastructure cannot follow symlinks. This used to work. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD-tests - Build #1675 - Unstable
FreeBSD_HEAD-tests - Build #1675 - Unstable:
Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1675/console
Change summaries:
No changes
The failed test cases:
6 tests failed.
FAILED: bin.sh.builtins.functional_test.case7
Error Message:
atf-check failed; see the output of the test for details
FAILED: bin.sh.builtins.functional_test.locale1
Error Message:
atf-check failed; see the output of the test for details
FAILED: lib.libc.locale.c16rtomb_test.c16rtomb_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.locale.mbrtoc16_test.mbrtoc16_test
Error Message:
Premature exit; test case received signal 11 (core dumped)
FAILED: lib.libc.stdio.print_positional_test.__test_cases_list__
Error Message:
Tester did not exit cleanly: kyua-atf-tester: Invalid test cases list header
'1..4'
FAILED:
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests
Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected
[123,456,78.0625]<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildincludes: don't know how to make libelf.h etc.
Hi everyone, I'm trying to build 11-CURRENT, but seeing missing header files in lib/libelf, lib/libdwarf and lib/nucurses during a seemingly simple `make buildworld' run. The include files land e.g. in a tmp/legacy/usr/include object path and copying them manually fixes that particular issue until the next error is triggered. I'm currently using 10.1 to build 11-CURRENT. Has anyone else seen this or has any idea how to solve this? Cheers, Franco ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
On 8 Nov 2015, at 02:32, Ulrich Spörlein wrote: > > > Git commit hashes *might* change in the future. I really don't > see how this is a big deal anyway. It happened once and I'm trying to > have it never happen again. But why are people afraid of this > happening? Every "official" git commit is tagged with a SVN revision > and the contents of those revisions are obviously correct (just not > the ancestry and the commit objects, possibly). So it would be easy to > write a script that replays VendorA's git history and swaps out the > new official commits for the old official commits. There would be no > merge conflicts. Git commit hashes must not change, or we completely destroy the utility of the git mirror for all downstream users. You can no longer do a merge from upstream git if the hashes in your local clone do not match the hashes downstream. Your answer of expecting every downstream user of FreeBSD’s git repo (GitHub tracks over 600 of them, there are likely more that are using private clones) to write a script to fix the mess for themselves is completely unacceptable. If there has been a window in which incorrect hashes were generated, this can be fixed by moving that to a branch, doing the correct thing in master, and then using git-imerge in rebase-with-history mode. After the point of the fix, there will be a single set of commits, but before that there will be two options as parents, one for each version of the export. Please remember that a guarantee of not changing the hashes of the history was one of the conditions that Core had for promoting this to an official FreeBSD service. David ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cannot installworld, don't expect to... part 2...
On Sat, 07 Nov 2015 19:14:47 -0800 (PST), "Jeffrey Bouquet" wrote: > I've a not-complete-installworld from today, dumped core halfway through > despite single-user mode... > > began with an install of libc++... which was fine. > > i can restore > /lib > /libexec > /bin > /sbin > /usr/bin > /usr/sbin > from an earlier backup > > and most binaries work again, but nowhere near > full functionality... wanting to restore browser > functionality... which mysteriously broke (all segfault) which > prompted the buildworld. > > setting COMPILER_TYPE results later in > sh: cc; not found during the installworld. > OTOH some buildworld > produced files may have been lost during the fsck to lost+found > > I noticed a few clang files ended up in lost+found during one of the many > fsck. > > So as an aside of any usual question... > Is there any documentation > where make installs should proceed? > for instance libc++ first, then ... > > and/or how to run the installworld segment-at-a-time to find the > specific failure? OR it is too complex > > Assuming "no" to each of the above... is there a best > practice to > copy a greater number of the /lib, libexec from > backup to completely restore, or is it necc. to > do a reinstall to an ENTIRELY new disk... given that > the existing disk for some reason does not want to > complete it. > > Maybe even someone has an easier way... or procedure. > > Thanks. > > ... > As an aside, a wanted feature: > > during one disk crash recently, the pass* in /etc wound up in lost+found. > No login resulted. Restored from backup by luck... was clueless. > Would it be wise to build redundancy into the base, so that for example > if /etc/fstab has vanished, its shadow copy in /etc/shadow/... > or even enough binaries, (similar /rescue ) to complete a complete svn > buildworld installworld as a sort of /rescue/usr/src with all binaries and > libraries contained therein. > > Maybe... > > Crash recovered. All /root/.* directories had vanished also... so I was thinking, maybe if fsck_ffs were more elaborate when placing the files in lost+found it would place metadata as to where it came from, and then lost+found-replace.sh or binary could recover FROM lost+found... I could be just wishing though. But the reason for this reply-followup rather than a new post (the paragraph above) with apologies... Now that the recovery here has been done, ( files between nov 3 and nov 7 copied from /mnt where the crashed disk(s) and backups were mounted)... WHAT is the best practice if *this* working r288246 (11.0-CURRENT) builds world, then core dumps during installworld, rendering login and/or paths upon login and/or segfaults of nano, etc after login and/or all working but browsers segfaulting after fixup... since this is a principal desktop ... ... the best practice for "if this installworld hoses, simply copy files from ..." recovery? OR, no one else knows either, which I think is more likely, in which case I apologize for even stating the question. Thanks. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
2015-11-08 11:32 GMT+01:00 Ulrich Spörlein : > 2015-11-08 2:51 GMT+01:00 Alfred Perlstein : >>> >> Uli, >> >> One of the biggest concerns I've heard from folks using FreeBSD's git mirror >> is that the hashes can change. >> >> I have a question about this. Is it possible to keep track of what the >> "official" git mirror (on github) is doing and keep that as a log. Then >> that log can be used to replay commits when there is a divergence problem. >> >> What I'm basically saying is that let's take this small example: >> >> importer is working fine @rev 1 >> imports 1 >> imports 10001 >> imports 10002 >> something happens to importer to give indeterminate shas. >> imports 10003 - sha is "unstable" sha3 >> imports 10004 - sha is "unstable" sha4 >> imports 10005 - sha is "unstable" sha5 >> imports 10006 - sha is "unstable" sha6 >> importer is fixed >> >> >> At this point normally we'd rewind the importer to 10002 and then force >> update the affected branches. >> >> My question is... can the imports of 10003, 10004, 10005 and 10006 be put >> into the importer such that any "mirror site" that re-does the import using >> the most up to date importer will get the same shas. >> >> That would allow to proceed with 10007, etc without force pushing. >> >> This should be possible based on querying "git" for the meta data associated >> with sha3..sha6 and then forcing those commits to have the same meta data. >> >> This would eliminate the concern about shas in the mirror changing that I've >> heard. > > The goal of the conversion is that everyone can re-do the conversion > in their basement and come up with the same history and checksums. > This was not the case when I first started, as there was some > non-deterministic hash structure being used in svn2git. This was fixed > in the code and then all converter runs produced the very same > results. > > The scenario that we have right now, is that one of the merge commits > done about two weeks ago is being handled different by svn2git w/ svn > v1.8 vs. svn v1.9 and I haven't investigated yet how the API's > behavior changed to cause this. I'm afraid I also swapped out all my > knowledge about svn2git internals and will have to redo this all from > scratch :/ > > Your suggestion could only work, if we hard-code this svn revision > special handling into svn2git, either in the code or by providing more > mappings and rules to the process. svn2git should run hermetic and not > poke at github's commits to see how things were handled in the past. > It has to be self-sufficient and must not depend on github. > > This would also only work, if the "breakage" window was very small, > but it is already about two weeks long and will surely increase till I > find the proper fix. > > So, to take a stand here: this sort of kludge is unlikely to ever > happen. Git commit hashes *might* change in the future. I really don't > see how this is a big deal anyway. It happened once and I'm trying to > have it never happen again. But why are people afraid of this > happening? Every "official" git commit is tagged with a SVN revision > and the contents of those revisions are obviously correct (just not > the ancestry and the commit objects, possibly). So it would be easy to > write a script that replays VendorA's git history and swaps out the > new official commits for the old official commits. There would be no > merge conflicts. > > I can see how this would be annoying if you have 100 developers and > dozens of branches that are far from mainline FreeBSD. But I'm sure > these companies that depend on git will come forward and donate some > of their developer manpower to help me with keeping the converter > stable/deterministic. Right? Right? :) :) > > Cheers, > Uli Quick update: doc is so far unaffected by svn 1.9, but for ports, the drift happened as of Jul 18, so you'd need to special case a lot of commits. Here's the same commit, and the difference between 1.8 and 1.9: % git cat-file commit 803795d tree 7fc83aba022834da5c218114b09ad4640735bcc0 parent c96fb0418e545a569b5975b4d878a30a948c29d5 author olgeni 1437203525 + committer olgeni 1437203525 + Upgrade to version 0.4.1. % git cat-file commit 61ca43b tree 7fc83aba022834da5c218114b09ad4640735bcc0 parent c96fb0418e545a569b5975b4d878a30a948c29d5 author olgeni 1437203529 + committer olgeni 1437203529 + Upgrade to version 0.4.1. In case you don't see it, there's a 4s difference in the timestamps for authoring and committing. Here's the original: % svn log -vc392405 svn://svn.freebsd.org/ports r392405 | olgeni | 2015-07-18 09:12:05 +0200 (Sat, 18 Jul 2015) | 2 lines Changed paths: M /head/www/elixir-maru/Makefile M /head/www/elixir-maru/distinfo Upgrade to version 0.4.1. So yeah, svn 1.9 returned a timestamp that was off by 4s. WTF? For base it's actu
FreeBSD_HEAD_i386 - Build #1622 - Fixed
FreeBSD_HEAD_i386 - Build #1622 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1622/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1622/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1622/console Change summaries: 290541 by skra: Make usermode variable the bool type. It's already used that way. Suggested by: kib Approved by:kib (mentor) 290540 by ngie: printfloat_test and scanfloat_test need symbols from msun; these are automatically provided on amd64, but not i386. Add libm to DPADD/LDADD to unbreak the i386 tinderbox Pointyhat to: ngie MFC after: 1 week X-MFC with: r290538 Sponsored by: EMC / Isilon Storage Division 290539 by ngie: Integrate tools/regression/lib/libc/string into the FreeBSD test suite as lib/libc/tests/string MFC after: 1 week Sponsored by: EMC / Isilon Storage Division ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: SVN to GIT converter currently broken, github is falling behind
2015-11-08 2:51 GMT+01:00 Alfred Perlstein : >> > Uli, > > One of the biggest concerns I've heard from folks using FreeBSD's git mirror > is that the hashes can change. > > I have a question about this. Is it possible to keep track of what the > "official" git mirror (on github) is doing and keep that as a log. Then > that log can be used to replay commits when there is a divergence problem. > > What I'm basically saying is that let's take this small example: > > importer is working fine @rev 1 > imports 1 > imports 10001 > imports 10002 > something happens to importer to give indeterminate shas. > imports 10003 - sha is "unstable" sha3 > imports 10004 - sha is "unstable" sha4 > imports 10005 - sha is "unstable" sha5 > imports 10006 - sha is "unstable" sha6 > importer is fixed > > > At this point normally we'd rewind the importer to 10002 and then force > update the affected branches. > > My question is... can the imports of 10003, 10004, 10005 and 10006 be put > into the importer such that any "mirror site" that re-does the import using > the most up to date importer will get the same shas. > > That would allow to proceed with 10007, etc without force pushing. > > This should be possible based on querying "git" for the meta data associated > with sha3..sha6 and then forcing those commits to have the same meta data. > > This would eliminate the concern about shas in the mirror changing that I've > heard. The goal of the conversion is that everyone can re-do the conversion in their basement and come up with the same history and checksums. This was not the case when I first started, as there was some non-deterministic hash structure being used in svn2git. This was fixed in the code and then all converter runs produced the very same results. The scenario that we have right now, is that one of the merge commits done about two weeks ago is being handled different by svn2git w/ svn v1.8 vs. svn v1.9 and I haven't investigated yet how the API's behavior changed to cause this. I'm afraid I also swapped out all my knowledge about svn2git internals and will have to redo this all from scratch :/ Your suggestion could only work, if we hard-code this svn revision special handling into svn2git, either in the code or by providing more mappings and rules to the process. svn2git should run hermetic and not poke at github's commits to see how things were handled in the past. It has to be self-sufficient and must not depend on github. This would also only work, if the "breakage" window was very small, but it is already about two weeks long and will surely increase till I find the proper fix. So, to take a stand here: this sort of kludge is unlikely to ever happen. Git commit hashes *might* change in the future. I really don't see how this is a big deal anyway. It happened once and I'm trying to have it never happen again. But why are people afraid of this happening? Every "official" git commit is tagged with a SVN revision and the contents of those revisions are obviously correct (just not the ancestry and the commit objects, possibly). So it would be easy to write a script that replays VendorA's git history and swaps out the new official commits for the old official commits. There would be no merge conflicts. I can see how this would be annoying if you have 100 developers and dozens of branches that are far from mainline FreeBSD. But I'm sure these companies that depend on git will come forward and donate some of their developer manpower to help me with keeping the converter stable/deterministic. Right? Right? :) :) Cheers, Uli ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD_HEAD_i386 - Build #1621 - Failure
FreeBSD_HEAD_i386 - Build #1621 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1621/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1621/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/1621/console Change summaries: 290538 by ngie: Integrate tools/regression/lib/libc/stdlib into the FreeBSD test suite as lib/libc/tests/stdlib - Make the code a bit more style(9) compliant - Convert a sizeof(x)/sizeof(x[0]) to nitems MFC after: 1 week Sponsored by: EMC / Isilon Storage Division 290537 by ngie: Integrate tools/regression/lib/libc/stdio into the FreeBSD test suite as lib/libc/tests/stdio - Fix some whitespace - Convert the testcases to ATF - Convert "/dev/null" to _PATH_DEVNULL MFC after: 1 week Sponsored by: EMC / Isilon Storage Division The end of the build log: [...truncated 95043 lines...] --- open_wmemstream_test.o --- cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/lib/libc/tests/stdio/open_wmemstream_test.c -o open_wmemstream_test.o --- all_subdir_gnu --- --- mipsread.o --- cc -O2 -pipe -Dxregcomp=regcomp -Dxre_exec=re_exec -Dxregexec=regexec -Dxre_search=re_search -Dxre_compile_fastmap=re_compile_fastmap -Dxregerror=regerror -Dxre_comp=re_comp -Dxre_set_syntax=re_set_syntax -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -DDEBUGDIR=\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/libgdb/../arch/i386 -I/usr/src/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/usr/src/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/include -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/gnu/usr.bin/gdb/libgdb/../../../lib/libreadline/readline/.. -std=gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/mipsrea d.c -o mipsread.o --- all_subdir_lib --- --- open_wmemstream_test --- cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Qunused-arguments -o open_wmemstream_test open_wmemstream_test.o -lprivateatf-c --- perror_test --- (cd /usr/src/lib/libc/tests/stdio && DEPENDFILE=.depend.perror_test NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/stdio/Makefile _RECURSING_PROGS= PROG=perror_test ) --- all_subdir_kerberos5 --- --- pkinit.po --- --- all_subdir_lib --- --- perror_test.o --- --- all_subdir_kerberos5 --- cc -pg -O2 -pipe -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/ipc -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/base -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -std=gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/pkinit.c -o pkinit.po --- all_subdir_lib --- cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/lib/libc/tests/stdio/perror_test.c -o perror_test.o --- all_subdir_gnu --- --- nlmread.o --- cc -O2 -pipe -Dxregcomp=regcomp -Dxre_exec=re_exec -Dxregexec=regexec -Dxre_search=re_search -Dxre_compile_fastmap=re_compile_fastmap -Dxregerror=regerror -Dxre_comp=re_comp -Dxre_set_syntax=re_set_syntax -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -DDEBUGDIR=\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/libgdb/../arch/i386 -I/usr/src/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd -I/usr/src/gnu/usr.bin/gdb/libgdb/../../binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/include -I/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/gnu/usr.bin/gdb/libgdb/../../../lib/libreadline/readline/.. -std=gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/nlmread .c -o nlmread.o --- all_subdir_lib --- --- perror_test --- cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Qunused-arguments -o perror_test perror_test.o -lprivateatf-c --- print_positional_test --- (cd /usr/src/lib/libc/tests/stdio && DEPENDFILE=.depend.print_positional_test NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/stdio/Makefile _RECURSING_PROGS= PROG=print_positional_test ) --- print_positional_test.o --- cc -O2 -pipe -std=gnu99 -fstack-protector-strong -Qunused-arguments -c /usr/src/lib/libc/tests/stdio/print_positional_test.c -o pri
