Searched hist:202 (Results 1 - 25 of 38) sorted by relevance
| /freebsd-current/usr.bin/xargs/tests/ | ||
| H A D | regress.R-1.out | 202adb22 Thu Jul 13 14:06:14 MDT 2023 Daniel Tameling <tamelingdaniel@gmail.com> xargs: fix -R so that it accepts negative numbers again fbc445addf9 converted the parsing of arguments to strtonum but made the accepted range for -R too restrictive. As documented in the man page, it should accept negative numbers. Added a test for this, which was provided by Jose Luis Duran. Fixes: fbc445addf9 MFC after: 1 week Reviewed by: des, kevans Differential Revision: https://reviews.freebsd.org/D41021 |
| H A D | Makefile | diff 202adb22 Thu Jul 13 14:06:14 MDT 2023 Daniel Tameling <tamelingdaniel@gmail.com> xargs: fix -R so that it accepts negative numbers again fbc445addf9 converted the parsing of arguments to strtonum but made the accepted range for -R too restrictive. As documented in the man page, it should accept negative numbers. Added a test for this, which was provided by Jose Luis Duran. Fixes: fbc445addf9 MFC after: 1 week Reviewed by: des, kevans Differential Revision: https://reviews.freebsd.org/D41021 |
| H A D | regress.sh | diff 202adb22 Thu Jul 13 14:06:14 MDT 2023 Daniel Tameling <tamelingdaniel@gmail.com> xargs: fix -R so that it accepts negative numbers again fbc445addf9 converted the parsing of arguments to strtonum but made the accepted range for -R too restrictive. As documented in the man page, it should accept negative numbers. Added a test for this, which was provided by Jose Luis Duran. Fixes: fbc445addf9 MFC after: 1 week Reviewed by: des, kevans Differential Revision: https://reviews.freebsd.org/D41021 |
| /freebsd-current/lib/libc/gen/ | ||
| H A D | tcgetwinsize.3 | 4e0c81c5 Fri Jan 01 15:28:42 MST 2021 Konstantin Belousov <kib@FreeBSD.org> tcgetwinsize(3): provide man page The current POSIX.1-202x draft (1.1) was used as source material. Submitted by: Soumendra Ganguly <soumendraganguly@gmail.com> MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D27787 |
| /freebsd-current/lib/googletest/tests/ | ||
| H A D | Makefile | diff 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| H A D | Makefile.inc | 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/gmock_main/ | ||
| H A D | Makefile | diff 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/gtest_main/ | ||
| H A D | Makefile | diff 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/gmock/ | ||
| H A D | Makefile | diff 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/tests/gmock/ | ||
| H A D | Makefile | 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/usr.sbin/unbound/setup/ | ||
| H A D | local-unbound-setup.sh | diff 202ec220 Sat May 12 12:07:53 MDT 2018 Dag-Erling Smørgrav <des@FreeBSD.org> If the sole non-option command line argument is "none", remove any pre-existing forwarder configuration and set Unbound up to recurse. PR: 222902 MFC after: 1 week |
| /freebsd-current/lib/googletest/tests/gtest/ | ||
| H A D | Makefile | 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/tests/gmock_main/ | ||
| H A D | Makefile | 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/tests/gtest_main/ | ||
| H A D | Makefile | 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/lib/googletest/gtest/ | ||
| H A D | Makefile | diff 2ed32360 Mon Oct 19 13:50:57 MDT 2020 Alex Richardson <arichardson@FreeBSD.org> Major improvement to build parallelism for googletest internal tests Currently the googletest internal tests build after the matching library. However, each of these is serialized at the top level makefile. Additionally some of the tests (e.g. the gmock-matches-test) take up to 90 seconds to build with clang -O2. Having to wait for this test to complete before continuing to the next directory seriously slows down the parllelism of a -j32 build. Before this change running `make -C lib/googletest -j32 -s` in buildenv took 202 seconds, now it's 153 due to improved parallelism. Reviewed By: emaste (no objection) Differential Revision: https://reviews.freebsd.org/D26748 |
| /freebsd-current/share/man/man4/ | ||
| H A D | zyd.4 | diff af5ab554 Thu Mar 07 06:26:54 MST 2013 Gavin Atkinson <gavin@FreeBSD.org> The ZyXEL ZyAIR G-202 is also supported by zyd(4) MFC after: 1 week |
| H A D | termios.4 | diff 4e0c81c5 Fri Jan 01 15:28:42 MST 2021 Konstantin Belousov <kib@FreeBSD.org> tcgetwinsize(3): provide man page The current POSIX.1-202x draft (1.1) was used as source material. Submitted by: Soumendra Ganguly <soumendraganguly@gmail.com> MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D27787 |
| /freebsd-current/share/misc/ | ||
| H A D | committers-doc.dot | diff b6d173e4 Mon Apr 24 13:00:45 MDT 2023 Graham Perrin <grahamperrin@FreeBSD.org> share/misc/committers-doc.dot: dru: 2020, not 202 Dru Lavigne's doc commit bit was taken in 2020-05-05 https://cgit.freebsd.org/doc/commit/access?h=refs/internal/admin&id=fb28136a81580786a66ab2494da40b01f4b7a75b Fixes: 52f576459855 committers-doc.dot: bring file up to date diff 202edfe3 Fri Jul 02 12:42:14 MDT 2021 Ceri Davies <ceri@FreeBSD.org> committers-doc.dot: move myself out of alumni |
| /freebsd-current/usr.sbin/cdcontrol/ | ||
| H A D | cdcontrol.1 | diff 202b18cd Sun Jan 14 09:29:24 MST 2001 Josef Karthauser <joe@FreeBSD.org> Describe that the CDROM environment variable now affects which device is used by default. |
| /freebsd-current/sys/arm/include/ | ||
| H A D | vmparam.h | diff da77382f Sat Jan 09 13:14:00 MST 2021 Kyle Evans <kevans@FreeBSD.org> arm: revert MAXDSIZ change from 202aea9c82ea This imposes a fairly severe limitation on space available for mmap that was not noticed prior to commit. Unfixed mmap will only map from [data + MAXSIZE, end of user VA space], bringing the amount of usable space down way too low for non-trivial link jobs (for instance). Reported by: mmel diff 202aea9c Thu Dec 31 10:12:39 MST 2020 Kyle Evans <kevans@FreeBSD.org> arm: tune vmparam.h towards a little more modern An 8MB max stack size is quite limiting in today's world, and in-fact is the *default* stack size for almost every other arch (including mips). Raise the default to 4MB (should be pretty reasonable) and the max to 64MB. NetBSD made a similar move back in 2015 and raised MAXDSIZ to 1856 at the same time, so let's just roll that in as well. They later lowered it, but eventually raised it back to 1856 in order to build rust. This was noticed while looking at qemu-bsd-user's default stack sizes and growth behavior (or lack thereof). Reviewed by: ian Differential Revision: https://reviews.freebsd.org/D27218 |
| /freebsd-current/share/man/man5/ | ||
| H A D | elf.5 | diff 202f6d83 Mon Mar 30 13:10:12 MDT 2020 Ed Maste <emaste@FreeBSD.org> elf.5: table markup fixes Suggested by 0mp in review D23982. Submitted by: 0mp |
| /freebsd-current/usr.sbin/inetd/ | ||
| H A D | builtins.c | diff 202a2323 Thu Jul 22 15:42:49 MDT 1999 Brian Feldman <green@FreeBSD.org> "knobs are cheap". Here's a -t timeout option for the internal ident service. It takes a number (w/ or w/out .usec) as an argument. |
| /freebsd-current/sys/geom/label/ | ||
| H A D | g_label_ufs.c | diff 202f0f2a Thu May 24 10:48:33 MDT 2012 Edward Tomasz Napierala <trasz@FreeBSD.org> Make g_label(4) ignore provider size when looking for UFS labels. Without it, it fails to create labels for filesystems resized by growfs(8). PR: kern/165962 Submitted by: Olivier Cochard-Labbe <olivier at cochard dot me> |
| /freebsd-current/tools/tools/nanobsd/ | ||
| H A D | nanobsd.sh | diff 202cd572 Sat Aug 13 02:06:18 MDT 2005 Poul-Henning Kamp <phk@FreeBSD.org> Prune empty directories in /usr Move argv parsing. |
| /freebsd-current/sys/dev/usb/wlan/ | ||
| H A D | if_zyd.c | diff 85531f08 Sun May 31 19:51:37 MDT 2009 Weongyo Jeong <weongyo@FreeBSD.org> ZyXEL G-202 has zd1211b chipset, not zd1211. Tested by: Samuel Boivie <samuel at boivie.org> |
Completed in 491 milliseconds