All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] e2fsprogs: 1.42.9 -> 1.43-WIP
Date: Sat, 16 Jan 2016 14:24:11 +0800	[thread overview]
Message-ID: <5699E20B.8050405@windriver.com> (raw)
In-Reply-To: <1452856537.28375.142.camel@linuxfoundation.org>



On 01/15/2016 07:15 PM, Richard Purdie wrote:
> On Thu, 2016-01-14 at 18:05 -0800, Robert Yang wrote:
>> Upgrade to 1.43-WIP to make "mke2fs -d" support xattr, so that the
>> layer
>> which requires xattr such as meta-selinux can populate images easily.
>>
>> * Remove the following patches since they are alredy in the source.
>>    0001-e2fsprogs-fix-cross-compilation-problem.patch
>>    0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch
>>    0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch
>>    0002-misc-create_inode.c-copy-files-recursively.patch
>>    0003-misc-create_inode.c-create-special-file.patch
>>    0004-misc-create_inode.c-create-symlink.patch
>>    0005-misc-create_inode.c-copy-regular-file.patch
>>    0006-misc-create_inode.c-create-directory.patch
>>    0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch
>>    0008-mke2fs.c-add-an-option-d-root-directory.patch
>>    0009-misc-create_inode.c-handle-hardlinks.patch
>>    0010-debugfs-use-the-functions-in-misc-create_inode.c.patch
>>    0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch
>>    0012-Fix-musl-build-failures.patch
>>    CVE-2015-0247.patch
>>    copy-in-create-hardlinks-with-the-correct-directory-.patch
>>    fix-icache.patch
>>    misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch
>>
>> * Remove cache_inode.patch since it is not needed any more
>>
>> * Updated mkdir.patch and ptest.patch
>>
>> * Add --enable-libblkid to EXTRA_OECONF since libblkid is not created
>> by
>>    default.
>>
>> * Time of core-image-sato-sdk do_rootfs:
>>    - Before upgrade
>>      real    3m18.508s
>>      user    7m42.088s
>>      sys     1m1.984s
>>
>>    - After upgrade
>>      real    3m21.552s
>>      user    7m38.496s
>>      sys     1m0.644s
>>
>>     The are nearly the same
>>
>> * The "fsck -fn" shows the image is OK, and also can boot.
>>
>> [YOCTO #8622]
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> [...]
>
>> -SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
>> -SRC_URI[sha256sum] =
>> "2f92ac06e92fa00f2ada3ee67dad012d74d685537527ad1241d82f2d041f2802"
>> +SRCREV = "0f26747167cc9d82df849b0aad387bf824f04544"
>> +PV = "1.43-WIP+git${SRCPV}"
>
> What happens when 1.43 is released? 1.43 < 1.43-WIP so we'd have to
> bump PE.
>
> Can we just call this 1.42+1.43-git${SRCPV}?

Thanks, good idea, updated in the repo:

   git://git.openembedded.org/openembedded-core-contrib rbt/e2fsprogs
 
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/e2fsprogs

Robert Yang (1):
   e2fsprogs: 1.42.9 -> 1.43 (master)

* Changes:
   - Use PV = "1.42+1.43-git${SRCPV}"

Another thing is that, though we use "1.42+1.43-git${SRCPV}", the rpm name is
e2fsprogs-1.42+1.43+git0+0f26747167-r0.aarch64.rpm, note, no "-" in PV, the
same to ipk.

// Robert

>
> I agree with moving to this btw, I just don't like the idea of "WIP" in
> the version string and we need to keep upgrade paths in mind.
>
> Cheers,
>
> Richard
>


  parent reply	other threads:[~2016-01-16  6:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  2:05 [PATCH 0/1] e2fsprogs: 1.42.9 -> 1.43-WIP Robert Yang
2016-01-15  2:05 ` [PATCH 1/1] " Robert Yang
2016-01-15 11:15   ` Richard Purdie
2016-01-15 11:23     ` Burton, Ross
2016-01-16  6:24     ` Robert Yang [this message]
2016-01-18  7:31     ` Patrick Ohly
2016-01-18  7:58       ` Robert Yang
2016-01-18 10:12         ` Patrick Ohly
2016-01-21  7:21   ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5699E20B.8050405@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.