public inbox for openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox