| /freebsd/contrib/ntp/ |
| H A D | README.pullrequests | 14 in seeing that work in the current production release then base your work
15 on the stable branch, and pull your work into a master copy to allow for
16 publishing your changes in the ntp-dev or master branch.
18 If there is no expectation that your work will be included in the
19 current stable release (the ntp-stable code) then it's better to do your
24 It's possible that after pulling your changes from stable to master that
29 incorporate your work.
31 Please also note that your submissions will be able to be evaluated and
32 handled sooner if the repo that contains your pull requests also includes
37 1) If you haven't, create a fork of ntp-project/ntp with your github account.
[all …]
|
| H A D | README.patches | 11 > (make and test your changes to ntp-stable first)
12 > (commit your changes to ntp-stable)
14 > bk pull ../ntp-stable (get your changes from ntp-stable)
15 > (resolve any problems and test your changes)
16 > (commit your changes to ntp-dev)
22 If you make your changes in the above order and then submit them,
23 it will be trivial to apply your patches.
25 Otherwise, it will be much more difficult to apply your patches.
27 You are pretty much done now if your repos are on pogo.udel.edu.
37 If you cannot easily get your patches to pogo, you may submit patches
[all …]
|
| /freebsd/tools/tools/git/ |
| H A D | HOWTO | 13 should demonstrate a logical progression towards your end goal. For example,
15 any current functionality. A subsequent commit could then introduce your new
18 It usually will not be helpful to present your code in the order in which it
20 introduced a bug early in your development process that you fixed in a
21 subsequent commit, it is a waste of your reviewer's time to have them review
24 presented to your reviewers in any review.
28 gives your reviewers the necessary context to understand your change.
30 2. Create your reviews by running this command in your git repo:
49 Next, make your change and perform whatever testing is necessary. Commit it
50 to your repository with this command:
[all …]
|
| /freebsd/sys/contrib/zstd/ |
| H A D | CONTRIBUTING.md | 14 We actively welcome your pull requests.
16 1. Fork the repo and create your branch from `dev`.
20 5. Make sure your code lints.
24 In order to accept your pull request, we need you to submit a CLA. You only need
27 Complete your CLA here: <https://code.facebook.com/cla>
37 * Checkout your fork of zstd if you have not already
42 * Update your local dev branch
48 * Make a new branch on your fork about the topic you're developing for
60 * Note: run local tests to ensure that your changes didn't break existing functionality
71 …* Before sharing anything to the community, create a pull request in your own fork against the dev…
[all …]
|
| /freebsd/usr.sbin/bsdconfig/include/ |
| H A D | network_device.hlp | 21 If you're using a modem then PPP is almost certainly your only choice.
22 Make sure that you have your service provider's information handy as
24 will need to know your service provider's IP address, the IP address
25 of your provider's DNS server, and possibly your own IP address unless
26 your ISP supports dynamic negotiation, most do. If you do not choose
28 "AT commands" to dial the ISP with your particular brand of modem as
31 can simply enter `dial' (without the quotes) at the ppp prompt if your
48 You will also need to know your IP address on the network, the
49 "netmask" value for your address class, and the name of your machine.
50 Your system administrator can tell you which values to use for your
[all …]
|
| /freebsd/contrib/kyua/ |
| H A D | CONTRIBUTING.md | 6 to get your changes incorporated.
12 * Before we can use your code, you must sign the
16 mainly because you own the copyright to your changes, even after your
17 contribution becomes part of our codebase, so we need your permission to use
18 and distribute your code. We also need to be sure of various other
19 things--for instance that you will tell us if you know that your code
21 after you have submitted your code for review and a member has approved it,
22 but you must do it before we can put your code into our codebase.
28 Please get your company to sign this agreement instead if your contribution is
31 * Unless you have a strong reason not to, please assign copyright of your
[all …]
|
| /freebsd/lib/libc/net/ |
| H A D | networks | 3 your-net 127 # your comment
4 your-netmask 255.255.255 # subnet mask for your-net
|
| H A D | hosts | 5 # share this file. Replace 'my.domain' below with the domainname of your
27 # real official assigned numbers. Do not try to invent your own network
28 # numbers but instead get one from your network provider (if any) or
29 # from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.)
|
| /freebsd/contrib/googletest/ |
| H A D | CONTRIBUTING.md | 1 # How to become a contributor and submit your own code
5 We'd love to accept your patches! Before we can take them, we have to jump a
14 * If you work for a company that wants to allow you to contribute your work,
20 accept your pull requests.
30 1. Submit an issue describing your proposed change to the
36 This ensures that work isn't being duplicated and communicating your plan
38 4. If your proposed change is accepted, and you haven't already done so, sign a
41 5. Fork the desired repo, develop and test your code changes.
42 6. Ensure that your code adheres to the existing style in the sample to which
44 7. Ensure that your code has an appropriate set of unit tests which all pass.
[all …]
|
| H A D | README.md | 57 Googletest automatically discovers and runs your tests, eliminating the need
58 to manually register your tests
61 exceptions, and more, making it easy to test your code
63 You can define your own assertions with Googletest, making it simple to
64 write tests that are specific to your code
66 Googletest supports death tests, which verify that your code exits in a
113 runs your test binary, allows you to track its progress via a progress bar, and
120 result output. If your test runner understands TAP, you may find it useful.
123 runs tests from your binary in parallel to provide significant speed-up.
127 your tests.
[all …]
|
| /freebsd/contrib/mandoc/ |
| H A D | INSTALL | 26 Before manually installing mandoc on your system, please check
32 Regarding how packages and ports are maintained for your operating
33 system, please consult your operating system documentation.
43 functionality as your system's "catman", if your operating
48 for your operating system.
51 This script attempts autoconfiguration of mandoc for your system.
107 If your system does not have them, the bundled compatibility version
115 If your system does not have it, the bundled compatibility version
127 on your platform, consider the following:
133 longer. If your system does need such magic, consider upgrading
[all …]
|
| /freebsd/contrib/less/ |
| H A D | README | 17 Software Foundation; either version 3, or (at your option) any
83 your system that configure might not have detected, you may fix the
90 If you choose not to include some features in your version, you may
98 "lesskey" and "lessecho" in your current directory. Test the
125 Depending on your compiler, you may need to convert the source
133 are correct. CC should be the name of your C compiler and
136 either modify the definitions directly in MAKEFILE, or set your
141 If you choose not to include some features in your version, you may
145 5. Run your "make" program and watch the fun.
146 If your "make" requires a flag to import environment variables,
[all …]
|
| /freebsd/share/examples/ipfilter/rules/ |
| H A D | nat-setup | 1 Configuring NAT on your network.
4 To start setting up NAT, we need to define which is your "internal" interface
5 and which is your "external" interface. The "internal" interface is the
10 For example, your internal interface might have an IP# of 10.1.1.1 and be
11 connected to your ethernet, whilst your external interface might be a PPP
14 Thus your network might look like this:
|
| /freebsd/contrib/sendmail/libmilter/ |
| H A D | README | 52 It is recommended that you build your filters in a location outside of
56 -lsocket -lnsl'. Depending on your operating system you may need a library
62 the Makefile in your appropriate obj.*/libmilter build subdirectory if you
66 process limits in your filter. For example, you might look at using
67 setrlimit() to increase the number of open file descriptors if your filter
83 specifies three filters. Filters can be specified in your .mc file using
128 INPUT_MAIL_FILTER commands in your .mc file. Alternatively, you can
129 reset its value by setting confINPUT_MAIL_FILTERS in your .mc file.
135 filter list by using MAIL_FILTER() instead of INPUT_MAIL_FILTER() in your
139 the appropriate locations) to your .mc file:
[all …]
|
| /freebsd/crypto/openssl/external/perl/Text-Template-1.56/ |
| H A D | README | 14 It has come to our attention that you are delinquent in your
16 ${sprintf("%.2f", $amount)} immediately, or your patellae may
29 It has come to our attention that you are delinquent in your
31 $392.12 immediately, or your patellae may
39 You can store a template in a file outside your program. People can
47 won't have to worry that they are tampering with your program when you
|
| /freebsd/crypto/openssl/doc/HOWTO/ |
| H A D | certificates.txt | 6 How you handle certificates depends a great deal on what your role is.
50 yourself if you have your own certificate authority or create a
67 complete, they send you your new certificate.
88 was kind enough, your certificate is a raw DER thing in PEM format.
91 things like PKCS7 or PKCS12, or something else. Depending on your
96 So, depending on your application, you may have to convert your
97 certificate and your key to various formats, most often also putting
101 right for your applications, simply concatenating the certificate and
106 By now, you have your certificate and your private key and can start
|
| /freebsd/contrib/dialog/samples/install/ |
| H A D | setup.help | 4 sure that nothing bad is done to your harddisk :-)
26 Setup will ask you for a partition on your harddisk,
29 your local harddisk or via network (NFS).
32 Rebooting your computer with this little linux system
39 create an extra partition on your harddisk for
|
| /freebsd/contrib/ntp/sntp/libopts/ |
| H A D | README | 12 1. Install the unrolled tarball into your package source tree,
13 copying ``libopts.m4'' to your autoconf macro directory.
15 In your bootstrap (pre-configure) script, you can do this:
32 to your configure.ac file. See LIBOPTS_CHECK: below for details.
34 3. Add the following to your top level ``Makefile.am'' file:
50 you need them in your build tree.
52 5. Make sure your object files explicitly depend upon the
71 If your package does not utilize the auto* tools, then you
120 Public License (see: COPYING.lgpl), or, at your option, the modified
|
| /freebsd/contrib/googletest/docs/ |
| H A D | quickstart-cmake.md | 5 this tutorial as a starting point. If your project uses Bazel, see the
35 project. You'll use this file to set up your project and declare a dependency on
38 First, create a directory for your project:
48 To do this, in your project directory (`my_project`), create a file named
80 your own project.
82 As an example, create a file named `hello_test.cc` in your `my_project`
98 behavior of your code. The above sample includes the main GoogleTest header file
101 To build the code, add the following to the end of your `CMakeLists.txt` file:
125 Now you can build and run your test:
|
| H A D | quickstart-bazel.md | 29 is a directory on your filesystem that you use to manage source files for the
34 First, create a directory for your workspace:
45 To do this, in the root directory of your workspace (`my_workspace/`), create a
68 With your Bazel workspace set up, you can now use GoogleTest code within your
71 As an example, create a file named `hello_test.cc` in your `my_workspace`
87 behavior of your code. The above sample includes the main GoogleTest header file
115 Now you can build and run your test:
|
| /freebsd/usr.bin/fortune/datfiles/ |
| H A D | freebsd-tips | 41 If other operating systems have damaged your Master Boot Record, you can
52 If you have a CD-ROM drive in your machine, you can make the CD-ROM that is
60 If you need a reminder to leave your terminal, type "leave +hhmm" where
75 someone logs in or out of your system.
77 If you use the C shell, add the following line to the .cshrc file in your
84 kilobytes instead of 512-byte blocks, set BLOCKSIZE in your
131 "man security" gives very good advice on how to tune the security of your
134 "man tuning" gives some tips how to tune performance of your FreeBSD system.
145 Need to leave your terminal for a few minutes and don't want to logout?
146 Use "lock -p". When you return, use your password as the key to unlock the
[all …]
|
| /freebsd/sys/contrib/openzfs/contrib/dracut/ |
| H A D | README.md | 3 2. Set `mountpoint=/` for your root dataset (for compatibility, `legacy` also works, but is not rec…
11 4. Or (b) append `root=zfs:pool/dataset` to your kernel cmdline.
12 5. Re-generate your initrd and update it in your boot bundle
45 …This has obvious potential for data loss: make sure your persistent data is not below the rootfs a…
|
| /freebsd/etc/sendmail/ |
| H A D | freebsd.mc | 38 # If you want to customize it, copy it to a name appropriate for your
70 dnl Uncomment to allow relaying based on your MX records.
71 dnl NOTE: This can allow sites to use your server as a backup MX without
72 dnl your permission.
82 dnl Uncomment to activate your chosen DNS based block list
84 dnl Alternatively, you can provide your own server and rejection message:
88 dnl define(`SMART_HOST', `your.isp.mail.server')
|
| /freebsd/sys/contrib/openzfs/.github/ |
| H A D | CONTRIBUTING.md | 46 or install stable packages from [your distribution's
76 found anything similar to your issue.
96 Be prepared to work with the developers investigating your issue. Your
104 * Whether your system has ECC memory.
118 If you have an idea for a feature first check this list. If your idea already
122 Otherwise, open a new issue and describe your proposed feature. Why is this
133 * Make sure your commit messages are in the correct format. See the
137 * For large pull requests consider structuring your changes as a stack of
150 …y tests will run. You can always override this by adding `ZFS-CI-Type` line to your commit message:
151 …* If your last commit (or `HEAD` in git terms) contains a line `ZFS-CI-Type: quick`, quick mode is…
[all …]
|
| /freebsd/contrib/googletest/googletest/ |
| H A D | README.md | 5 To build GoogleTest and your tests that use it, you need to tell your build
18 the compiler environment of your choice. You can either build GoogleTest as a
70 used between GoogleTest and the rest of your project, so issues associated with
90 Just add to your `CMakeLists.txt`:
152 If GoogleTest doesn't correctly detect whether pthread is available in your
165 When GoogleTest uses pthread, you may need to add flags to your compiler and/or
167 CMake script, this is taken care of for you. If you use your own build script,
168 you'll need to read your compiler and linker's manual to figure out what flags
184 library instead - consult your linker's manual for how to do it.
186 To compile your *tests* that use the gtest shared library, add
[all …]
|