Re: [PATCH 1/1] V2 Fix libpam's chmod

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-03-02 at 14:31 +0100, Koen Kooi wrote:
> Op 2 mrt. 2012, om 14:26 heeft Richard Purdie het volgende geschreven:
> 
> > On Fri, 2012-03-02 at 18:34 +0800, Robert Yang wrote:
> >> The libpam's has an error when generating the rootfs:
> >> 
> >> chmod: cannot access `/usr/sbin/unix_chkpwd': No such file or directory
> >> 
> >> This is because the following code in libpam_1.1.5.bb:
> >> 
> >> pkg_postinst_pam-plugin-unix () {
> >>    # below is necessary to allow unix_chkpwd get user info from shadow file
> >>    # on lsb images
> >>    chmod 4755 ${sbindir}/unix_chkpwd
> >> }
> >> 
> >> This is to set the setuid permission for unix_chkpwd (the lsb test
> >> requires this), but it lacks a "${D}", and we can do this in the install
> >> stage.
> >> 
> >> [YOCTO #2049]
> >> 
> >> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> > 
> > Robert, in future patches could you use a subject line like:
> > 
> > [PATCH 1/1 v2] Fix libpam's chmod
> > 
> > instead of:
> > 
> > [PATCH 1/1] V2 Fix libpam's chmod
> > 
> > so that when the patches get applied, the V2 is stripped off?
> > 
> > The reason is that the value isn't particularly within the repository
> > once merged and doesn't look good when looking through commit history.
> 
> Actually both versions above are wrong, the right version would be similar to:
> 
> libpam 1.1.5: fix chmod in postinst
> 
> We can debate the usefulness of the version specifier, but we do need to follow the commit guide for the rest.

Good point, I was just commenting that the patch version specifier
didn't look good. As you say, the package name should be first too, as
per http://wiki.openembedded.org/wiki/Commit_Patch_Message_Guidelines
under Common Errors in Patch and Commit Messages: '- Short log does not
start with the file or component being modified. Such as "foo: Update to
new upstream version 5.8.9"'.

If I was going to be picky, I'd suggest capitalisation of "fix" in your
version ;-)

Cheers,

Richard