NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Most of what follows can also be found under
bk helptool terms
. I just wanted to restructure it slightly for the audience I'm writing it for but, yes, I shamelessly stole chunks of this straight from the helptool page. I've ordered these definitions so that it makes sense to read them top down. (If you think there are commands that would be useful to run in order to better understand any of these definitions, feel free to add them.)
: A package
represents a logical
collection of files, like the Linux 2.6.8 kernel package, or the gcc-3.3.4 package. A repository
represents an instance
of that package, so a single package might be represented by numerous repositories out there, each with its own developer making his own changes. A repository is also sometimes called a work space
or a clone
: There are two kinds of identities. Each BK package has a unique package identity
that is the same across all copies or instances of that package, while each repository has its own repository identity
, regardless of its underlying package. You can list each of these identities with:
$ bk id # package identity
$ bk id -r # repository identity
: Source Code Control System
, the underlying source code management (SCM) system used to keep track of the actual files and directories and their revision history. When you first clone a repository, chances are none of the files will be visible in their regular
locations, but their internal SCCS files will be in their respective
directories. To work with a file, you'd normally check it out or edit it.
: A gfile
(or "gotten" file) is the regular file name that would be used by a developer, like
, while the sfile
(or sometimes s.file
) is the underlying SCCS file representing that file and all of its revision history, which you would find in the corresponding file
. If you wanted to examine or do some work on a file, you'd first have to check out
that file, which would create the gfile
from its corresponding sfile
. If you really want to see a directory's sfiles without actually checking anything out, just run:
$ ls SCCS
in that directory.
: This generally refers to files in your repository that aren't under any revision control; that is, perhaps temporary junk that you may have created but have no intention of checking in. You can see these files with the command:
$ bk extras
: When you want to either examine or make changes to a file, you would normally check out
to get the corresponding gfile
. It seems traditional to say that, if you just want to examine a file in read-only mode, you'd "check it out", while if you want to get the file in writable form to make changes to it, you'd talk of "editing" the file, but this difference in terminology is not cast in stone.
: The word diff
is generally used to describe the difference between a file's sfile
, and its checked out gfile
. If you edit a file, make some changes and just save those changes to your current gfile form of that file, that file now has a diff. Note that this is before you check any changes back in. If you pop back into the editor, make more changes and save the file again, the diff for that file will now be larger, but it will still be considered as one diff, not two smaller diffs.
To see all of the current diffs in a repo, just type:
$ bk -r diffs
: Once you've decided that you like the changes you've made to a file and saved from the editor, you can check it in
, which will update the corresponding sfile in the
directory and increment its revision number
. Once you do that, the file is no longer considered to have a "diff" since your edited version agrees with the sfile in the
directory. (Note carefully that just checking in a file doesn't mean you're committing to it just yet. That comes later. Keep reading.)
: When you check in an updated copy of a file, this increments its revision number
. You might also refer to any given revision of a file as a delta
of that file, but that depends on the context. The word "delta" might refer to a specific revision of a file, or it might be used to represent the difference
between a version of a file and its previous version. Again, it's all based on the context.
If you want a quick summary of a file's revision history, just type something like:
$ bk prs README
and see the helptool page for
for more options.
: This term refers to files that have been checked out, edited and modified and saved, and checked in, but not yet committed to a changeset. If you want to see everything that's currently pending, just type:
$ bk pending
: After you edit possibly multiple files, make changes and check those files back in, you can commit all of those changes, which generates a new changeset
. As we've already mentioned, you can get a list of all of your currently-uncommitted but checked-in changes with:
$ bk pending
: A changeset
(also abbreviated cset
) is a collection of files and their revisions that are logically related, and that represent the unit of repository modification that is exchanged between repositories (well, that and patches
). Normally, you'd group a collection of file revisions into a changeset because they represent a single, functional change or improvement to the repository, like "Upgraded USB support to 2.0".
Note that it's possible for a file to have more than one revision in a single changeset. If you edited file
, figured you were done with it and checked it in, it might get a new revision number of, say, 1.11. If you realize you forgot something in that file, re-edited it, saved it and checked the newer version in, it would get the revision number 1.12. If you then committed that file as part of a new changeset, that changeset would contain both
revisions of that file.
If you want some brief information on your repo's changesets, try any of the following:
$ bk changes -r+ -nd:REV: # latest changeset revision number
$ bk changes -r+ # general purpose of last changeset
$ bk changes -r<rev number> # general purpose of a given changeset
Finally, the changeset history of a repository is stored in the file named
: A key
is a unique, unchanging identifier for a version of a file that can be used anywhere a regular version or revision number for that file can be used. You can extract the key for a particular file revision in one of two ways, depending on the key format that you want; for example:
$ bk prs -hr<rev> -nd:KEY: Makefile # human readable
$ bk prs -hr<rev> -nd:MD5KEY: Makefile # not so human readable
bk helptool terms
page shows a different version of the above commands:
$ bk -R prs -hr<rev> -nd:KEY: Makefile
$ bk -R prs -hr<rev> -nd:MD5KEY: Makefile
option means that the command will be run relative to the root of the repository, which is probably not what you want if you happen to be in a subdirectory somewhere.
: A tag
or symbolic name
can be given to any revision of your repository, so you can associate a meaningful name with some snapshot of the repo. You can get a list of all of the tags in your current repo with:
$ bk tags
which is just a short form for
bk changes -t