[PATCH 0/4] Pull Request

[PATCH 0/4] Pull Request

[J William Piggott]

 sys-utils/hwclock.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

The following changes since commit 85bfb519afcbccccb63849b1a348dde76ff6bb83:

  switch_root: unlink files without _DIRENT_HAVE_D_TYPE (2017-04-26 11:23:50 +0200)

are available in the git repository at:

  git@github.com:jwpi/util-linux.git 170419

for you to fetch changes up to 57415653a667cf2442d019f62287534931ab3da4:

  hwclock: use a consistent name for --predict (2017-04-26 23:19:56 -0400)

----------------------------------------------------------------
J William Piggott (4):
      hwclock: extra messages for debug only
      hwclock: make clock test mode message consistent
      hwclock: remove unneeded braces
      hwclock: use a consistent name for --predict

 sys-utils/hwclock.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

Re: [PATCH 0/4] Pull Request

[Karel Zak]

On Wed, Apr 26, 2017 at 11:29:40PM -0400, J William Piggott wrote:
>       hwclock: extra messages for debug only
>       hwclock: make clock test mode message consistent
>       hwclock: remove unneeded braces
>       hwclock: use a consistent name for --predict

Applied, thanks.

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

[PATCH 0/4] pull request

[J William Piggott]

docs: various changes; see patches for details.

The following changes since commit 3947ca4ca9737d830f54658ef353f5626c0d0282:

  build-sys: ncurses headers cleanup (2017-05-31 11:01:46 +0200)

are available in the git repository at:

  git@github.com:jwpi/util-linux.git 170529

for you to fetch changes up to 80008bcae9a1aed3d38507a319155a69c4414509:

  docs: move source-code-management.txt to README (2017-05-31 11:36:47 -0400)

----------------------------------------------------------------
J William Piggott (4):
      docs: update v2.30-ReleaseNotes
      docs: update howto-contribute.txt
      docs: update howto-contribute.txt
      docs: move source-code-management.txt to README

 Documentation/howto-contribute.txt        | 201 +++++++++++++++---------------
 Documentation/release-schedule.txt        |   2 +-
 Documentation/releases/v2.30-ReleaseNotes |  38 +++---
 Documentation/source-code-management.txt  |  38 ------
 README                                    | 121 +++++++++++++-----
 5 files changed, 215 insertions(+), 185 deletions(-)
 delete mode 100644 Documentation/source-code-management.txt

[PATCH 1/4] docs: update v2.30-ReleaseNotes

[J William Piggott]

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 Documentation/releases/v2.30-ReleaseNotes | 38 ++++++++++++++++---------------
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/Documentation/releases/v2.30-ReleaseNotes b/Documentation/releases/v2.30-ReleaseNotes
index 3702178..f9a45a1 100644
--- a/Documentation/releases/v2.30-ReleaseNotes
+++ b/Documentation/releases/v2.30-ReleaseNotes
@@ -1,39 +1,41 @@
-Util-linux 2.30 Release Notes 
-============================= 
+Util-linux 2.30 Release Notes
+=============================
 
-The libblkid library has been fixed to extract LABEL= and UUID= from UDF
-rather than from ISO9660 header on hybrid CDROM/DVD media. This changes
-makes UDF media on Linux user-space more compatible with another operation
-systems. Unfortunately, this change may introduce regression for (unusual)
-hybrid CDROM/DVDs where ISO and UDF use a different LABEL=.
+The libblkid library has been improved for hybrid CDROM/DVD media by extracting
+the LABEL and UUID values from the UDF header, rather than the ISO9660 header.
+This change makes hybrid CDROM/DVD media created on other operating systems more
+compatible in Linux user-space. Unfortunately, this change may introduce a
+regression for (unusual) hybrid CDROM/DVDs where the ISO and UDF headers use a
+different LABEL.
 
 The deprecated command tailf has been removed. Use "tail -f" from coreutils.
 
-blkzone -- NEW COMMAND to run zone commands on block device that support Zoned
+blkzone -- NEW COMMAND to run zone commands on block devices that support Zoned
 Block Commands (ZBC) or Zoned-device ATA Commands (ZAC). The currently
 supported functionality is 'report' and 'reset'.
 [thanks to Shaun Tancheff (Seagate), Damien Le Moal (WD)]
 
-fincore -- NEW COMMAND to count pages of file contents in core (memory). 
+fincore -- NEW COMMAND to count pages of file contents in core (memory).
 [thanks to Masatake YAMATO (Red Hat)]
 
 lsmem -- NEW COMMAND to list the ranges of available memory with their online
-status (originally implemented in Perl for s390-tools). [thanks to Clemens von Mann 
+status (originally implemented in Perl for s390-tools). [thanks to Clemens von Mann
 and Heiko Carstens (IBM)]
 
 chmem -- NEW COMMAND to set memory online/offline status [thanks to Heiko
 Carstens (IBM)]
 
-The old and dead Alpha and Cmos code has been removed from hwclock command.
+Removed Alpha and dead code from hwclock's --directisa option.
 
-The command fallocate supports "insert range" operation now.
+The command fallocate supports an "insert range" operation now.
 
-The command "column -t|--table" has been modified to use libsmartcols. Now it
-provides almost all functionality of the library on command line, for example
-print header for table, reorder columns, align columns to the right, print
-tree-like output, wrap lines in cells, truncate text in cells, etc.
+The command "column -t|--table" has been modified to use libsmartcols. It now
+provides nearly all of that library's functionality from the command line. For
+example: printing a table header, reordering columns, aligning columns
+to the right, printing tree-like output, wrapping lines in cells, truncating
+text in cells, etc.
 
-The libmount library provides API to generate exit codes and error/warning
+The libmount library now provides an API to generate exit codes and error/warning
 messages compatible with mount(8).
 
 
@@ -48,7 +50,7 @@ CVE-2016-2779 - This security issue is NOT FIXED yet.  It is possible to
   disable the ioctl TIOCSTI by setsid() only.  Unfortunately, setsid()
   has well-defined use cases in su(1) and runuser(1) and any changes
   would introduce regressions.  It seems we need a better way -- ideally
-  another ioctl to disable TIOCSTI without setsid() or in userspace
+  another ioctl to disable TIOCSTI without setsid() or in a userspace
   implemented pty container (planned as experimental su(1) feature).
 
 

[PATCH 2/4] docs: update howto-contribute.txt

[J William Piggott]

Grammar fixes and some clarification changes.

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 Documentation/howto-contribute.txt | 154 +++++++++++++++++++------------------
 1 file changed, 81 insertions(+), 73 deletions(-)

diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index 6d3e789..729f4cb 100644
--- a/Documentation/howto-contribute.txt
+++ b/Documentation/howto-contribute.txt
@@ -1,43 +1,50 @@
 Patches
 
-	* send your patches to the mailing list or to the upstream maintainer
-	  (see the README file in project root directory).
+	* send your patches to the mailing list or to the project maintainer.
+	  See ../README.
 
-	* don't include generated (autotools) stuff to your patches (hint:
-	  use git clean -Xd)
+	* don't include generated (autotools) files in your patches.
+	  Hint: use 'git clean -Xd'.
 
-	* neutrality; The stuff in util-linux should be rather
-	  distribution-neutral. No RPMs/DEBs/... are provided - get yours
-	  from your distributor.
+	* neutrality: the files in util-linux should be distribution-neutral.
+	  Packages like RPMs, DEBs, and the rest, are not provided. They should
+	  be available from the distribution.
 
-	* patches are delivered via email or git remote repository only.
-	  Downloading them from internet servers is a pain.  See
-	  howto-pull-request.txt for remote repository instructions.
+	* email is accepted as an inline patch with, or without, a git pull
+	  request. Pull request emails need to include the patch set for review
+	  purposes. See howto-pull-request.txt and source-code-management.txt
+	  for git repository instructions.
 
-	* one patch per email, with the changelog in the body of the email.
+	* one patch per email.
+	  See Email Format.
 
-	* mail attachments are difficult. Tip:
-	  git send-email --to util-linux@vger.kernel.org origin/master..yourbranch
+	* email attachments are difficult to review and not recommended.
+	  Hint: use 'git send-email'.
 
-	* many small patches are favoured over one big. Break down is done on
-	  basis of logical functionality; for example #endif mark ups,
-	  compiler warning and exit codes fixes all should be individual
+	* many small patches are preferred over a single large patch. Split
+	  patch sets based upon logical functionality. For example: #endif mark
+	  ups, compiler warnings, and exit code fixes should all be individual
 	  small patches.
 
-	* 'Subject: [PATCH] subsystem: description'. See also 'Patching
-	  process'.
+Email Format
+
+	* Subject: [PATCH] subsystem: description.
+
+	* Start the message body with an explanation of the patch, that is, a
+	  changelog/commit entry.
 
 	* if someone else wrote the patch, they should be credited (and
-	  blamed) for it. To communicate this, add a line:
+	  blamed) for it. To communicate this, add a line like:
 
 	  From: John Doe <jdoe@wherever.com>
 
-	* add a Signed-off-by line (hint: use "git commit -s")
+	* add a Signed-off-by line.
+	  Hint: use git commit -s
 
 	  The sign-off is a simple line at the end of the explanation for the
 	  patch, which certifies that you wrote it or otherwise have the
 	  right to pass it on as a open-source patch. The rules are pretty
-	  simple: if you can certify the below:
+	  simple; if you can certify the following:
 
 	  By making a contribution to this project, I certify that:
 
@@ -64,92 +71,94 @@ Patches
 	       consistent with this project or the open source license(s)
 	       involved.
 
-	  then you just add a line saying
+	  Then you just add a line like:
 
 	       Signed-off-by: Random J Developer <random@developer.example.org>
 
-	  using your real name (sorry, no pseudonyms or anonymous
-	  contributions.)
+	  Use your real name (sorry, no pseudonyms or anonymous contributions.)
+
+	* Next a single line beginning with three hyphen-minus characters (---)
+	  and nothing else.
+
+	* Followed by the unified diff patch.
 
 Before sending a patch
 
-	* make sure that after patching source files will compile without
-	  errors.
+	* make sure that after applying your patch the file(s) will compile
+	  without errors.
 
-	* test that previously existed program behavior is not
-	  unintentionally alterred. If you alter the behavior tell about
-	  it in commit message.
+	* test that the previously existing program behavior is not altered. If
+	  the patch intentionally alters the behavior explain what changed, and
+	  the reason for it, in the changelog/commit message.
 
 Coding style
 
-	* the preferred coding style is based on the linux kernel
-	  Documentation/CodingStyle. For more details see:
+	* the preferred coding style is based on the linux kernel coding-style.
+	  Available here:
 
-	  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodingStyle
+	http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/coding-style.rst
 
-	* Use `FIXME:' and a good description if want to inform others
-	  something is not quite right, and you are unwilling to fix the
+	* use 'FIXME:' with a good description, if you want to inform others
+	  that something is not quite right, and you are unwilling to fix the
 	  issue in the submitted change.
 
 Patching process
 
-	* Tell in mail list when you are going to work with some particular
-	  piece of code for long time.  This helps other to avoid massive
-	  merge conflicts.  Small or quick work does not need to be
+	* announce it on the mailing list when you are going to work with some
+	  particular piece of code for a long time. This helps others to avoid
+	  massive merge conflicts. Small or quick work, does not need to be
 	  announced.
 
-	* Submit only changes that you think are ready to merge.  If you only
-	  want change review tell your intention clearly in change cover
-	  letter, and/or in each patch subject to review-only.
+	* only submit changes that you believe are ready to merge. To post a
+	  patch for peer review only, state it clearly in the email and use
+	  the Subject: [PATCH RFC] ...
 
-	* When getting comments align the changes with them.  Resubmission
-	  without changes is as good as ignoring advice, and is neither
-	  recommended nor polite.
+	* incorporate reviewer comments in the patches. Resubmitting without
+	  changes is neither recommended nor polite.
 
-	* Resubmission can be partial or complete.  If only few alterations
-	  are needed here and there resubmit particular patches.  When
-	  comments cause greater effect resubmit everything again.
+	* resubmission can be partial or complete. If only a few alterations are
+	  needed then resubmit those particular patches. When comments cause a
+	  greater effect then resubmit the entire patch set.
 
-	* Mark resubmission with [PATCH v2]. Hint:
-	  git format-patch origin/master..yourbranch --subject-prefix='PATCH v2'
+	* When resubmitting use the email Subject: [PATCH v2] ...
+	  Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
 
-	* Use of remote repository for resubmission can be good idea.
-	  See also howto-pull-request.txt
+	* using a git repository for (re)submissions can make life easier.
+	  See howto-pull-request.txt and source-code-management.txt.
 
-	* All patch submissions, big or small, are either commented, reject,
-	  or merge.  When maintainer rejects a patch (series) it is pointless
-	  to resubmit.
+	* all patch submissions are either commented, rejected, or accepted.
+	  If the maintainer rejects a patch set it is pointless to resubmit it.
 
 Various notes
 
-	* The util-linux does not use kernel headers for file system super
+	* util-linux does not use kernel headers for file system super
 	  blocks structures.
 
-	* Patches relying on features that are not in Linus' tree
-	  are not accepted.
+	* patches relying on kernel features that are not in Linus Torvalds's
+	  tree are not accepted.
 
-	* Do not use `else' after non-returning functions. For
-	  example
+	* do not use `else' after non-returning functions. For
+	  example:
 
 	  if (this)
 		err(EXIT_FAIL, "this failed");
 	  else
 		err(EXIT_FAIL, "that failed");
 
-	  is wrong and should be wrote
+	  Is wrong and should be written:
 
 	  if (this)
 		err(EXIT_FAIL, "this failed");
 	  err(EXIT_FAIL, "that failed");
 
-	* When you use if shortshort hand make sure it is not wrapped to
-	  multiple lines. In case the shorthand does not look good on one
-	  line use normal "if () else" syntax.
+	* when you use 'if' short-shorthand make sure it does not wrap into
+	  multiple lines. In case the shorthand does not look good on one line
+	  use the normal "if () else" syntax.
 
-Standards compliancy
+Standards compliance
 
 	Some of the commands maintained in this package have Open Group
-	requirements. These commands are;
+	requirements. These commands are:
 
 		cal
 		col
@@ -164,11 +173,10 @@ Standards compliancy
 		pg
 		renice
 
-	If you change these tools please make sure a change does not
-	conflict with the latest standard.  For example it is
-	recommendable not to add short command line options before they
-	are part of standard.  Introducing new long options is
-	acceptable.
+	If you change these tools please make sure it does not create a conflict
+	with the latest standard. For example, it is not recommended to add
+	short command line options before they are part of the standard.
+	Introducing new long options is acceptable.
 
 		The Single UNIX(TM) Specification, Version 2
 		Copyright (C) 1997 The Open Group
@@ -177,10 +185,10 @@ Standards compliancy
 
 IRC channel
 
-	* We have a new #util-linux IRC channel at freenode.net.
+	* #util-linux at freenode.net:
 
 	  irc://chat.freenode.net/util-linux
 
-	  the channel is for developers or upstream maintainers.  User
-	  support is recommended to go to distribution channels or
-	  forums.
+	  This channel is for developers and project maintainers. For end users
+	  it is recommended to utilize the distribution's IRC channel or support
+	  forum.

[PATCH 3/4] docs: update howto-contribute.txt

[J William Piggott]

This patch does not change any wording or grammar. It
only shuffles the order of things and adds a table of
contents. For example: it moves coding related bullet
points into the Coding Style Chapter; it groups email
related Chapters together, and so fourth.

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 Documentation/howto-contribute.txt | 123 ++++++++++++++++++++-----------------
 1 file changed, 65 insertions(+), 58 deletions(-)

diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index 729f4cb..fc2c503 100644
--- a/Documentation/howto-contribute.txt
+++ b/Documentation/howto-contribute.txt
@@ -1,31 +1,74 @@
-Patches
+CONTENTS
+ Sending Patches
+ Patching Process
+ Email Format
+ Coding Style
+ Various Notes
+ Standards Compliance
+ IRC Channel
+
+Sending Patches
 
 	* send your patches to the mailing list or to the project maintainer.
 	  See ../README.
 
-	* don't include generated (autotools) files in your patches.
-	  Hint: use 'git clean -Xd'.
-
-	* neutrality: the files in util-linux should be distribution-neutral.
-	  Packages like RPMs, DEBs, and the rest, are not provided. They should
-	  be available from the distribution.
-
 	* email is accepted as an inline patch with, or without, a git pull
 	  request. Pull request emails need to include the patch set for review
 	  purposes. See howto-pull-request.txt and source-code-management.txt
 	  for git repository instructions.
 
+	* email attachments are difficult to review and not recommended.
+	  Hint: use git send-email.
+
 	* one patch per email.
 	  See Email Format.
 
-	* email attachments are difficult to review and not recommended.
-	  Hint: use 'git send-email'.
-
 	* many small patches are preferred over a single large patch. Split
 	  patch sets based upon logical functionality. For example: #endif mark
 	  ups, compiler warnings, and exit code fixes should all be individual
 	  small patches.
 
+	* don't include generated (autotools) files in your patches.
+	  Hint: use 'git clean -Xd'.
+
+	* neutrality: the files in util-linux should be distribution-neutral.
+	  Packages like RPMs, DEBs, and the rest, are not provided. They should
+	  be available from the distribution.
+
+Patching Process
+
+	* announce it on the mailing list when you are going to work with some
+	  particular piece of code for a long time. This helps others to avoid
+	  massive merge conflicts. Small or quick work, does not need to be
+	  announced.
+
+	* make sure that after applying your patch the file(s) will compile
+	  without errors.
+
+	* test that the previously existing program behavior is not altered. If
+	  the patch intentionally alters the behavior explain what changed, and
+	  the reason for it, in the changelog/commit message.
+
+	* only submit changes that you believe are ready to merge. To post a
+	  patch for peer review only, state it clearly in the email and use
+	  the Subject: [PATCH RFC] ...
+
+	* incorporate reviewer comments in the patches. Resubmitting without
+	  changes is neither recommended nor polite.
+
+	* resubmission can be partial or complete. If only a few alterations are
+	  needed then resubmit those particular patches. When comments cause a
+	  greater effect then resubmit the entire patch set.
+
+	* When resubmitting use the email Subject: [PATCH v2] ...
+	  Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
+
+	* using a git repository for (re)submissions can make life easier.
+	  See howto-pull-request.txt and source-code-management.txt.
+
+	* all patch submissions are either commented, rejected, or accepted.
+	  If the maintainer rejects a patch set it is pointless to resubmit it.
+
 Email Format
 
 	* Subject: [PATCH] subsystem: description.
@@ -82,16 +125,7 @@ Email Format
 
 	* Followed by the unified diff patch.
 
-Before sending a patch
-
-	* make sure that after applying your patch the file(s) will compile
-	  without errors.
-
-	* test that the previously existing program behavior is not altered. If
-	  the patch intentionally alters the behavior explain what changed, and
-	  the reason for it, in the changelog/commit message.
-
-Coding style
+Coding Style
 
 	* the preferred coding style is based on the linux kernel coding-style.
 	  Available here:
@@ -102,41 +136,6 @@ Coding style
 	  that something is not quite right, and you are unwilling to fix the
 	  issue in the submitted change.
 
-Patching process
-
-	* announce it on the mailing list when you are going to work with some
-	  particular piece of code for a long time. This helps others to avoid
-	  massive merge conflicts. Small or quick work, does not need to be
-	  announced.
-
-	* only submit changes that you believe are ready to merge. To post a
-	  patch for peer review only, state it clearly in the email and use
-	  the Subject: [PATCH RFC] ...
-
-	* incorporate reviewer comments in the patches. Resubmitting without
-	  changes is neither recommended nor polite.
-
-	* resubmission can be partial or complete. If only a few alterations are
-	  needed then resubmit those particular patches. When comments cause a
-	  greater effect then resubmit the entire patch set.
-
-	* When resubmitting use the email Subject: [PATCH v2] ...
-	  Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
-
-	* using a git repository for (re)submissions can make life easier.
-	  See howto-pull-request.txt and source-code-management.txt.
-
-	* all patch submissions are either commented, rejected, or accepted.
-	  If the maintainer rejects a patch set it is pointless to resubmit it.
-
-Various notes
-
-	* util-linux does not use kernel headers for file system super
-	  blocks structures.
-
-	* patches relying on kernel features that are not in Linus Torvalds's
-	  tree are not accepted.
-
 	* do not use `else' after non-returning functions. For
 	  example:
 
@@ -155,7 +154,15 @@ Various notes
 	  multiple lines. In case the shorthand does not look good on one line
 	  use the normal "if () else" syntax.
 
-Standards compliance
+Various Notes
+
+	* util-linux does not use kernel headers for file system super
+	  blocks structures.
+
+	* patches relying on kernel features that are not in Linus Torvalds's
+	  tree are not accepted.
+
+Standards Compliance
 
 	Some of the commands maintained in this package have Open Group
 	requirements. These commands are:
@@ -183,7 +190,7 @@ Standards compliance
 
 		http://pubs.opengroup.org/onlinepubs/7908799/xcuix.html
 
-IRC channel
+IRC Channel
 
 	* #util-linux at freenode.net:
 

[PATCH 4/4] docs: move source-code-management.txt to README

[J William Piggott]

source-code-management.txt and README had similar content so combine
them in README.

Change Documentation/source-code-management.txt references to README.

Remove Documentation/source-code-management.txt.

Move IRC Channel information to README

Expand information about git branches and tags in README.

Add workflow to README; written by Karel Zak <kzak@redhat.com>

Signed-off-by: J William Piggott <elseifthen@gmx.com>
---
 Documentation/howto-contribute.txt       |  18 +----
 Documentation/release-schedule.txt       |   2 +-
 Documentation/source-code-management.txt |  38 ----------
 README                                   | 121 +++++++++++++++++++++++--------
 4 files changed, 96 insertions(+), 83 deletions(-)
 delete mode 100644 Documentation/source-code-management.txt

diff --git a/Documentation/howto-contribute.txt b/Documentation/howto-contribute.txt
index fc2c503..71b9ed7 100644
--- a/Documentation/howto-contribute.txt
+++ b/Documentation/howto-contribute.txt
@@ -5,17 +5,16 @@ CONTENTS
  Coding Style
  Various Notes
  Standards Compliance
- IRC Channel
 
 Sending Patches
 
-	* send your patches to the mailing list or to the project maintainer.
+	* send your patches to the mailing list.
 	  See ../README.
 
 	* email is accepted as an inline patch with, or without, a git pull
 	  request. Pull request emails need to include the patch set for review
-	  purposes. See howto-pull-request.txt and source-code-management.txt
-	  for git repository instructions.
+	  purposes. See howto-pull-request.txt and ../README for git repository
+	  instructions.
 
 	* email attachments are difficult to review and not recommended.
 	  Hint: use git send-email.
@@ -64,7 +63,7 @@ Patching Process
 	  Hint: use the --subject-prefix='PATCH v2' option with 'git format-patch'
 
 	* using a git repository for (re)submissions can make life easier.
-	  See howto-pull-request.txt and source-code-management.txt.
+	  See howto-pull-request.txt and ../README.
 
 	* all patch submissions are either commented, rejected, or accepted.
 	  If the maintainer rejects a patch set it is pointless to resubmit it.
@@ -190,12 +189,3 @@ Standards Compliance
 
 		http://pubs.opengroup.org/onlinepubs/7908799/xcuix.html
 
-IRC Channel
-
-	* #util-linux at freenode.net:
-
-	  irc://chat.freenode.net/util-linux
-
-	  This channel is for developers and project maintainers. For end users
-	  it is recommended to utilize the distribution's IRC channel or support
-	  forum.
diff --git a/Documentation/release-schedule.txt b/Documentation/release-schedule.txt
index 728de4d..0e12694 100644
--- a/Documentation/release-schedule.txt
+++ b/Documentation/release-schedule.txt
@@ -39,4 +39,4 @@ For all releases it is required that:
 See also
 --------
 
-Documentation/source-code-management.txt
+../README
diff --git a/Documentation/source-code-management.txt b/Documentation/source-code-management.txt
deleted file mode 100644
index ffa90d0..0000000
--- a/Documentation/source-code-management.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-SCM (source code management):
-
-    Primary repository:
-	git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
-
-    Backup repository:
-	git clone git://github.com/karelzak/util-linux.git
-
-Note that 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 the both repositories in the same time.
-
-Branches:
-
-    * maintenance (stable) branch
-	- created for every <major>.<minor> release
-	- branch name: stable/v<major>.<minor>
-
-    * master branch
-	- the status of this branch is: "it works for me". It
-	  means useful but not well tested patches.
-	- it's source for occasional snapshots
-	- for long-term development or invasive changes should be
-	  an active development forked into a separate branch
-	  (topic branches) from the tip of "master".
-
-Tags:
-
-    * A new tag object is created for:
-	- every release, tag name: v<version>, see "git tag -l" for
-          more information
-        - all tags are signed by maintainer's PGP key
-
-    * KNOWN BUGS:
-	- don't use tag v2.13.1 (created and published by mistake),
-          use v2.13.1-REAL.
diff --git a/README b/README
index 803f5dd..81e0504 100644
--- a/README
+++ b/README
@@ -1,67 +1,128 @@
 
-                                  util-linux
+				  util-linux
 
-              util-linux is a random collection of Linux utilities
+		util-linux is a random collection of Linux utilities
 
-     Note that in years 2006-2010 this project used the name "util-linux-ng".
+     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
 
+IRC CHANNEL:
 
-DOWNLOAD:
+      #util-linux at freenode.net:
 
-      https://www.kernel.org/pub/linux/utils/util-linux/
+      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
 
-      Note that upstream community has no resources to provide support for end
-      users with distribution specific issues. It's strongly recommended to 
-      report bugs to the distribution (downstream) maintainers by distribution
-      bug tracking systems. 
+      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:
 
-      See also Documentation/howto-contribute.txt
-               Documentation/source-code-management.txt
+ Download archive:
+	  https://www.kernel.org/pub/linux/utils/util-linux/
+
+ SCM (Source Code Management) Repository:
 
-      Web interface:
-          http://git.kernel.org/cgit/utils/util-linux/util-linux.git
-          https://github.com/karelzak/util-linux
+    Primary repository:
+	  git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
 
-      Checkout:
-          git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
+    Backup repository:
+	  git clone git://github.com/karelzak/util-linux.git
 
-      Note that GitHub repository may contain temporary development branches too.
+    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 the both repositories in the same time.
+      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'.
 
-NLS (PO TRANSLATIONS):
+	  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'
 
-      PO files are maintained by:
-          http://translationproject.org/domain/util-linux.html
+    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.
 
-VERSION SCHEMA:
+WORKFLOW EXAMPLE:
 
-      Standard releases:
+ 1) development (branch: <master>)
 
-          <major>.<minor>[.<maint>[.<bugfix>]]
+ 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
 
-             major = fatal and deep changes
-             minor = typical release with new features
-             maint = maintenance releases; bug fixes only
-             bugfix = unplanned releases for critical/security bugs
+ 3) development (work on v2.30, branch: <master>)
 
-      Development releases:
+ 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.
 
-         <major>.<minor>-rc<N>

Re: [PATCH 0/4] pull request

[Karel Zak]

On Wed, May 31, 2017 at 02:45:23PM -0400, J William Piggott wrote:
>   git@github.com:jwpi/util-linux.git 170529

Applied, thanks.

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

[PATCH 0/4] pull request

[J William Piggott]

* Rudi didn't like cluttering boilerplate.c with seldom used USAGE_*
  constants and I don't disagree with that point. I do think they should
  be in the file for new contributor discovery purposes. As a compromise
  I added the missing ones as a comment.

* the newly added USAGE_COLUMNS could be used in disk-utils/fdisk-list.c:432
  if Karel wants to drop the ' (for -o)'. I did not change it.

* I couldn't test the blkzone change to USAGE_COMMANDS, but I expect it to
  be okay.
   configure: WARNING: linux/blkzoned.h header not found; not building blkzone


The following changes since commit 2a14beb4e9c6cdf4466993741d86e45dd57ddef3:

  agetty: fix login name DEL/CTRL^U issue (2017-06-23 14:26:47 +0200)

are available in the git repository at:

  git@github.com:jwpi/util-linux.git 170622

for you to fetch changes up to 7948117da5654311dba59b256d9a017d56877592:

  Docs: move option naming to howto-contribute.txt (2017-06-24 15:22:49 -0400)

----------------------------------------------------------------
J William Piggott (4):
      include/c.h: add USAGE_COMMANDS and USAGE_COLUMNS
      Docs: add a comment for constants to boilerplate.c
      Docs: update howto-usage-function.txt
      Docs: move option naming to howto-contribute.txt

 Documentation/boilerplate.c            |  8 +--
 Documentation/howto-contribute.txt     | 25 +++++++++
 Documentation/howto-usage-function.txt | 97 +++++++++++++---------------------
 disk-utils/sfdisk.c                    |  2 +-
 include/c.h                            |  4 +-
 login-utils/lslogins.c                 |  6 +--
 misc-utils/findmnt.c                   |  3 +-
 sys-utils/blkzone.c                    |  2 +-
 sys-utils/lscpu.c                      |  3 +-
 sys-utils/lsmem.c                      |  5 +-
 sys-utils/wdctl.c                      |  3 +-
 11 files changed, 78 insertions(+), 80 deletions(-)

Re: [PATCH 0/4] pull request

[Karel Zak]

On Sun, Jun 25, 2017 at 05:45:56PM -0400, J William Piggott wrote:
> 
> * Rudi didn't like cluttering boilerplate.c with seldom used USAGE_*
>   constants and I don't disagree with that point. I do think they should
>   be in the file for new contributor discovery purposes. As a compromise
>   I added the missing ones as a comment.
> 
> * the newly added USAGE_COLUMNS could be used in disk-utils/fdisk-list.c:432
>   if Karel wants to drop the ' (for -o)'. I did not change it.

I think USAGE_COLUMNS should be good enough everywhere and the
additional notes (like ' (for -o)') are unnecessary.

Maybe we can change the text to "Available output columns:" to make it
more specific for readers.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH 0/4] pull request

[Karel Zak]

On Mon, Jun 26, 2017 at 10:27:44AM +0200, Karel Zak wrote:
> On Sun, Jun 25, 2017 at 05:45:56PM -0400, J William Piggott wrote:
> > 
> > * Rudi didn't like cluttering boilerplate.c with seldom used USAGE_*
> >   constants and I don't disagree with that point. I do think they should
> >   be in the file for new contributor discovery purposes. As a compromise
> >   I added the missing ones as a comment.
> > 
> > * the newly added USAGE_COLUMNS could be used in disk-utils/fdisk-list.c:432
> >   if Karel wants to drop the ' (for -o)'. I did not change it.
> 
> I think USAGE_COLUMNS should be good enough everywhere and the
> additional notes (like ' (for -o)') are unnecessary.
> 
> Maybe we can change the text to "Available output columns:" to make it
> more specific for readers.

 Implemented & pull request merged. Thanks.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH 0/4] pull request

[J William Piggott]

On 06/26/2017 04:27 AM, Karel Zak wrote:
> On Sun, Jun 25, 2017 at 05:45:56PM -0400, J William Piggott wrote:
>>
>> * Rudi didn't like cluttering boilerplate.c with seldom used USAGE_*
>>   constants and I don't disagree with that point. I do think they should
>>   be in the file for new contributor discovery purposes. As a compromise
>>   I added the missing ones as a comment.
>>
>> * the newly added USAGE_COLUMNS could be used in disk-utils/fdisk-list.c:432
>>   if Karel wants to drop the ' (for -o)'. I did not change it.
> 
> I think USAGE_COLUMNS should be good enough everywhere and the
> additional notes (like ' (for -o)') are unnecessary.
> 
> Maybe we can change the text to "Available output columns:" to make it
> more specific for readers.

Since we cannot guarantee that the 'output' option name will always be
available. It might be better to stay generic with the header and
instead create the reference in the option description like:

 -o, --output <list>    columns to display (see Columns:)

 Columns:
      SOURCE  source device
      ...

This would also keep the Columns header format consistent with the others.

On a somewhat related note; in recent discussion I've been trying to
promote the idea of using consistent language. For example, with all of
the synonyms: output, show, to stdout, display, print, etc. I think it
would be helpful to both users and translators to choose one to be used
consistently. Especially for technical writing it is important to use
consistent terms.

An idea from the Linux man-pages project is that man-pages.7 has a list
of preferred terms/spellings; perhaps util-linux could have a list of
preferred terms to be used in documentation and message strings?

We also might want to consider replacing Documentation/howto-man-page.txt
with a link to, or a copy of, man-pages.7. Michael and company have
added a lot to it in recent times.


> 
>     Karel
> 
> 

Re: [PATCH 0/4] pull request

[Karel Zak]

On Mon, Jun 26, 2017 at 09:47:42AM -0400, J William Piggott wrote:
> 
> 
> On 06/26/2017 04:27 AM, Karel Zak wrote:
> > On Sun, Jun 25, 2017 at 05:45:56PM -0400, J William Piggott wrote:
> >>
> >> * Rudi didn't like cluttering boilerplate.c with seldom used USAGE_*
> >>   constants and I don't disagree with that point. I do think they should
> >>   be in the file for new contributor discovery purposes. As a compromise
> >>   I added the missing ones as a comment.
> >>
> >> * the newly added USAGE_COLUMNS could be used in disk-utils/fdisk-list.c:432
> >>   if Karel wants to drop the ' (for -o)'. I did not change it.
> > 
> > I think USAGE_COLUMNS should be good enough everywhere and the
> > additional notes (like ' (for -o)') are unnecessary.
> > 
> > Maybe we can change the text to "Available output columns:" to make it
> > more specific for readers.
> 
> Since we cannot guarantee that the 'output' option name will always be
> available.

I have already pushed "Available output columns:" :-) 

The "output" does not mean any option in this case.

> It might be better to stay generic with the header and
> instead create the reference in the option description like:
> 
>  -o, --output <list>    columns to display (see Columns:)
> 
>  Columns:
>       SOURCE  source device
>       ...

Anyway, I like this "see Columns:" idea. Go ahead and send patch.

> On a somewhat related note; in recent discussion I've been trying to
> promote the idea of using consistent language. For example, with all of
> the synonyms: output, show, to stdout, display, print, etc. I think it
> would be helpful to both users and translators to choose one to be used
> consistently. Especially for technical writing it is important to use
> consistent terms.
> 
> An idea from the Linux man-pages project is that man-pages.7 has a list
> of preferred terms/spellings; perhaps util-linux could have a list of
> preferred terms to be used in documentation and message strings?

Sounds good. (but I hope we will have no endless "bike-shed
color" discussion about the terms)

> We also might want to consider replacing Documentation/howto-man-page.txt
> with a link to, or a copy of, man-pages.7. Michael and company have
> added a lot to it in recent times.

Documentation/howto-man-page.txt is a template, if you want to write new
tool than it should be good enough to cp(1) this template and use it.
I'd like to keep it there.

We can rename the file to Documentation/boilerplate.1 and rewrite
Documentation/howto-man-page.txt to the real how-to with link to the
Michal's man-pages.7.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

[PATCH 0/4] Pull Request

[J William Piggott]

The following changes since commit 8ffa3b651d7e74acba8f1d831b7f68fdb3c66aae:

  libfdisk: make fdisk compliant to UEFI/GPT specification on PMBR (2017-07-14 12:48:18 +0200)

are available in the git repository at:

  git@github.com:jwpi/util-linux.git 170711

for you to fetch changes up to c26ddc568f3fb26b45a22cbf89d3294113e70377:

  hwclock: improve RTC epoch messages (2017-07-16 08:41:54 -0400)

----------------------------------------------------------------
J William Piggott (4):
      hwclock: --epoch presence test fails
      hwclock: remove dead ioctl check
      hwclock: improve RTC epoch messages
      hwclock: improve RTC epoch messages

 sys-utils/hwclock-rtc.c | 56 +++++++++++++++++++------------------------------
 sys-utils/hwclock.8.in  |  3 +++
 sys-utils/hwclock.c     | 24 +++++++--------------
 sys-utils/hwclock.h     |  2 +-
 4 files changed, 32 insertions(+), 53 deletions(-)

Re: [PATCH 0/4] Pull Request

[Karel Zak]

On Sun, Jul 16, 2017 at 01:46:38PM -0400, J William Piggott wrote:
>  sys-utils/hwclock-rtc.c | 56 +++++++++++++++++++------------------------------
>  sys-utils/hwclock.8.in  |  3 +++
>  sys-utils/hwclock.c     | 24 +++++++--------------
>  sys-utils/hwclock.h     |  2 +-
>  4 files changed, 32 insertions(+), 53 deletions(-)

Applied, thanks.

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

[PATCH 0/4] Pull Request

[J William Piggott]

This patch set address four bugs. Three are related to ISO 8601 formats
and the fourth is a tangentially related bug in hwclock. 

Patch 0002 increases the ISO 8601 buffer macro from 32 to 42 which should
work for the first three, and may be usable in the last four files:
  login-utils/last.c:1039	buffer size 32
  misc-utils/uuidparse.c:231	uses ISO_8601_BUFSIZ + 4
  login-utils/utmpdump.c:94	buffer size 40
  login-utils/lslogins.c:316	buffer size 64
  sys-utils/lsipc.c:1328	buffer size 64
  sys-utils/dmesg.c:887		buffer size 256
  term-utils/script.c:351	uses BUFSIZ (8K on my system)

I haven't tested it on them.

The the final patch adds some common ISO timestamp format masks.

The following changes since commit b41bac08abadbea9bac7a093c995ca53d86c76f1:

  build-sys: move rfkill to /usr/sbin (2017-10-20 14:59:16 +0200)

are available in the git repository at:

  git@github.com:jwpi/util-linux.git 170925

for you to fetch changes up to a9f92c6d1f25f4111f1334bdb2dd96f8b4ccb9ba:

  lib/timeutils: add common ISO timestamp masks (2017-10-21 20:55:01 -0400)

----------------------------------------------------------------
J William Piggott (4):
      hwclock: add iso-8601 overflow check
      lib/timeutils: ISO_8601_BUFSIZ too small
      lib/timeutils: add get_gmtoff()
      lib/timeutils: add common ISO timestamp masks

 include/timeutils.h    | 23 ++++++++++++-----
 lib/timeutils.c        | 70 +++++++++++++++++++++++++++++++++++++++++++++++---
 login-utils/last.c     |  2 +-
 login-utils/lslogins.c |  3 +--
 login-utils/utmpdump.c |  4 +--
 misc-utils/uuidparse.c | 10 ++------
 sys-utils/dmesg.c      |  4 +--
 sys-utils/hwclock.c    | 23 +++++++----------
 sys-utils/lsipc.c      |  2 +-
 sys-utils/rfkill.c     |  8 ++----
 term-utils/script.c    |  8 ++----
 11 files changed, 103 insertions(+), 54 deletions(-)

[PATCH 0/4] Pull Request

[J William Piggott]

The following changes since commit 44d753407d6b751f022ef234c85785ccd99c5590:

  tests: unlocks on failed ts_scsi_debug_init (2017-12-07 15:08:29 +0100)

are available in the git repository at:

  git@github.com:jwpi/util-linux.git 171121

for you to fetch changes up to 6cdc7b9c02b251120eb014c4dbc2387d47e7fb46:

  lib/timeutils.c: warn format_iso_time() overflow (2017-12-09 18:43:29 -0500)

----------------------------------------------------------------
J William Piggott (4):
      lib/timeutils.c: bug fix Segmentation fault
      lib/timeutils.c:strxxx_iso: test conversion errors
      lib/timeutils.c:strxxx_iso: do not wrap tm_year
      lib/timeutils.c: warn format_iso_time() overflow

 lib/timeutils.c     | 46 +++++++++++++++++++++++++++++++---------------
 sys-utils/hwclock.c |  5 ++---
 2 files changed, 33 insertions(+), 18 deletions(-)

Re: [PATCH 0/4] Pull Request

[Karel Zak]

On Sun, Dec 10, 2017 at 10:47:04AM -0500, J William Piggott wrote:
> J William Piggott (4):
>       lib/timeutils.c: bug fix Segmentation fault
>       lib/timeutils.c:strxxx_iso: test conversion errors
>       lib/timeutils.c:strxxx_iso: do not wrap tm_year
>       lib/timeutils.c: warn format_iso_time() overflow


Merged, thanks!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com