Test nr. 2: Enable and fix warnings from 'test-groff'. Input file is /tmp/fallocate.1 <fallocate.1>:10 (macro IR): only 1 argument, but more are expected <fallocate.1>:24 (macro RB): only 1 argument, but more are expected <fallocate.1>:25 (macro IR): only 1 argument, but more are expected chk_manuals: Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z and Test nr. 15: Change the name of a macro for two fonts (e.g., BR and IR) to one letter, if there is only one argument. Add the second argument if needed. It is sometimes part of the first one. 10:.IR length 24:.RB \-l 25:.IR length ##### Test nr. 12: Change -- in x--y to \(em (em-dash), or, if an option, to \-\- 65:You can think of this option as doing a "\fBcp --sparse\fP" and then renaming ##### Test nr. 20: Use a macro to change to the italic font, instead of \fI [1], if possible. The macros have the italic corrections, but "\c" removes them. [1] man-pages(7) 39:The \fIlength\fR and \fIoffset\fR 50:to be collapsed starts at \fIoffset\fP and continues 51:for \fIlength\fR bytes. At the completion of the operation, the contents of 52:the file starting at the location \fIoffset\fR+\fIlength\fR will be appended at the 53:location \fIoffset\fR, and the file will be \fIlength\fR bytes smaller. The option 71:Insert a hole of \fIlength\fR bytes from \fIoffset\fR, shifting existing data. 85:\fIoffset\fP and continuing for \fIlength\fR bytes. Within the 103:Zeroes space in the byte range starting at \fIoffset\fP and 104:continuing for \fIlength\fR bytes. Within the specified range, blocks are ##### Test nr. 27: Split lines longer than 80 characters into two or more lines. Apropriate break points are the end of a sentence and a subordinate clause. fallocate.1: line 45 length 86 fallocate.1: line 52 length 83 fallocate.1: line 53 length 83 fallocate.1: line 100 length 95 ##### Test nr. 28: Wrong distance between sentences or protect the indicator. 1) Separate the sentences and subordinate clauses; each begins on a new line. See man-pages(7) and "info groff". Or 2) Adjust space between sentences (two spaces), 3) or protect the indicator by adding "\&" after it. The "indicator" is an "end-of-sentence character" (.!?). 99:Enable POSIX operation mode. In that mode allocation operation always completes, ##### Test nr. 37: Have a space after a comma in an argument to an alternating fonts macro. The space belongs to the comma, so ', '. 48:.BR \-c , " \-\-collapse\-range" 58:.BR \-d , " \-\-dig\-holes" 70:.BR \-i , " \-\-insert\-range" 73:.BR \-l , " \-\-length " \fIlength 76:.BR \-n , " \-\-keep\-size" 80:.BR \-o , " \-\-offset " \fIoffset 83:.BR \-p , " \-\-punch\-hole" 95:.BR \-v , " \-\-verbose" 98:.BR \-x , " \-\-posix" 102:.BR \-z , " \-\-zero\-range" 119:.BR \-V , " \-\-version" 122:.BR \-h , " \-\-help" ##### Test nr. 38: Email addresses use the macro ".MT" and end with ".ME". 125:.UR sandeen@redhat.com 129:.UR kzak@redhat.com ##### Test nr. 40: Add a comma before "and", "or", or "nor" if a series contains three or more words 41:MiB (=1024*1024), and so on for GiB, TiB, PiB, EiB, ZiB and YiB (the "iB" is 43:KB (=1000), MB (=1000*1000), and so on for GB, TB, PB, EB, ZB and YB. 45:The options \fB\-\-collapse\-range\fP, \fB\-\-dig\-holes\fP, \fB\-\-punch\-hole\fP and ##### Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is> |
||
---|---|---|
Documentation | ||
bash-completion | ||
config | ||
disk-utils | ||
include | ||
lib | ||
libblkid | ||
libfdisk | ||
libmount | ||
libsmartcols | ||
libuuid | ||
login-utils | ||
m4 | ||
misc-utils | ||
po | ||
schedutils | ||
sys-utils | ||
term-utils | ||
tests | ||
text-utils | ||
tools | ||
.editorconfig | ||
.gitignore | ||
.travis-functions.sh | ||
.travis.yml | ||
AUTHORS | ||
COPYING | ||
ChangeLog | ||
Makefile.am | ||
NEWS | ||
README | ||
README.licensing | ||
autogen.sh | ||
configure.ac | ||
util-linux.doap |
README
util-linux util-linux is a random collection of Linux utilities Note: for the years 2006-2010 this project was named "util-linux-ng". MAILING LIST: E-MAIL: util-linux@vger.kernel.org URL: http://vger.kernel.org/vger-lists.html#util-linux The mailing list will reject email messages that contain: - more than 100K characters - html - spam phrases/keywords See: http://vger.kernel.org/majordomo-info.html#taboo IRC CHANNEL: #util-linux at freenode.net: irc://chat.freenode.net/util-linux The IRC channel and Mailing list are for developers and project maintainers. For end users it is recommended to utilize the distribution's support system. BUG REPORTING: E-MAIL: util-linux@vger.kernel.org Web: https://github.com/karelzak/util-linux/issues This project has no resources to provide support for distribution specific issues. For end users it is recommended to utilize the distribution's support system. NLS (PO TRANSLATIONS): PO files are maintained by: http://translationproject.org/domain/util-linux.html VERSION SCHEMA: Standard releases: <major>.<minor>[.<maint>] major = fatal and deep changes minor = typical release with new features maint = maintenance releases; bug fixes only Development releases: <major>.<minor>-rc<N> SOURCE CODE: Download archive: https://www.kernel.org/pub/linux/utils/util-linux/ SCM (Source Code Management) Repository: Primary repository: git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git Backup repository: git clone git://github.com/karelzak/util-linux.git Web interfaces: http://git.kernel.org/cgit/utils/util-linux/util-linux.git https://github.com/karelzak/util-linux Note: the GitHub repository may contain temporary development branches too. The kernel.org repository contains master (current development) and stable/* (maintenance) branches only. All master or stable/* changes are always pushed to both repositories at the same time. Repository Branches: 'git branch -a' master branch - current development - the source for stable releases when deemed ready. - day-to-day status is: 'it works for me'. This means that its normal state is useful but not well tested. - long-term development or invasive changes in active development are forked into separate 'topic' branches from the tip of 'master'. stable/ branches - public releases - branch name: stable/v<major>.<minor>. - created from the 'master' branch after two or more release candidates and the final public release. This means that the stable releases are committed, tagged, and reachable in 'master'. - these branches then become forked development branches. This means that any changes made to them diverge from the 'master' branch. - maintenance releases are part of, and belong to, their respective stable branch. As such, they are tags(<major>.<minor>.<maint>) and not branches of their own. They are not part of, visible in, or have anything to do with the 'master' development branch. In git terminology: maintenance releases are not reachable from 'master'. - when initially cloned (as with the 'git clone' command given above) these branches are created as 'remote tracking branches' and are only visible by using the -a or -r options to 'git branch'. To create a local branch use the desired tag with this command: 'git checkout -b v2.29.2 v2.29.2' Tags: 'git tag' - a new tag object is created for every release. - tag name: v<version>. - all tags are signed by the maintainer's PGP key. Known Bugs: - don't use tag v2.13.1 (created and published by mistake), use v2.13.1-REAL instead. WORKFLOW EXAMPLE: 1) development (branch: <master>) 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>) 3) development (work on v2.30, branch: <master>) 4) fork -- create a new branch <stable/v2.29> based on tag v2.29 4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>) 4b) stable release (tag: v2.29.1, branch: <stable/v2.29>) 4c) more patches; another release (tag: v2.29.2, branch: <stable/v2.29>) 5) master release v2.30 (branch: <master>) ... where 3) and 4) happen simultaneously.