Hi Alexander,
Thank you very much, I will try it later:-).
// Robert
On 12/15/2017 09:35 PM, Alexander Kanavin wrote:
On 12/14/2017 06:38 PM, Alexander Kanavin wrote:
Got it, thanks.
I just sent the patches to yocto@ ML and published them on github - please do
try them out, and rebase you
On 12/14/2017 06:38 PM, Alexander Kanavin wrote:
Got it, thanks.
I just sent the patches to yocto@ ML and published them on github -
please do try them out, and rebase your patchset on top (some of it may
no longer be relevant).
I did the rebase myself, and pushed the result here - please
On 12/14/2017 04:13 AM, Robert Yang wrote:
How about simply issuing 'git revert' after a build has failed?
That's easier to implement than rearranging the order of commits,
and the commit message can include a link to the build failure logs.
Sounds reasonable to me, I will update the patch.
On 12/13/2017 09:18 PM, Alexander Kanavin wrote:
On 12/13/2017 03:16 AM, Robert Yang wrote:
How about simply issuing 'git revert' after a build has failed? That's easier
to implement than rearranging the order of commits, and the commit message
can include a link to the build failure logs.
On 12/13/2017 03:16 AM, Robert Yang wrote:
How about simply issuing 'git revert' after a build has failed? That's
easier to implement than rearranging the order of commits, and the
commit message can include a link to the build failure logs.
Sounds reasonable to me, I will update the patch.
On 12/12/2017 08:26 PM, Alexander Kanavin wrote:
On 12/11/2017 08:13 AM, Robert Yang wrote:
I think it's a simpler and easier to understand approach. Yes, this means
that an updated recipe that is close to the root of dependency tree can cause
a cascade of build failures (e.g. glibc), but th
On 12/11/2017 08:13 AM, Robert Yang wrote:
I think it's a simpler and easier to understand approach. Yes, this
means that an updated recipe that is close to the root of dependency
tree can cause a cascade of build failures (e.g. glibc), but the
update commits for everything else will still be
On 12/08/2017 10:18 PM, Alexander Kanavin wrote:
On 12/08/2017 04:00 AM, Robert Yang wrote:
I'm not sure, the logical *without* this patch is:
1) Do the commit when succeed or failed.
2) git format-patch
3) Remove the commit if failed, and leave the commit there if succeed
Sorry, "remove t
On 12/08/2017 04:00 AM, Robert Yang wrote:
I'm not sure, the logical *without* this patch is:
1) Do the commit when succeed or failed.
2) git format-patch
3) Remove the commit if failed, and leave the commit there if succeed
Sorry, "remove the comit if failed" is added by this patch, and why
On 12/08/2017 09:43 AM, Robert Yang wrote:
Hi Alexander,
Thanks for the quick reply.
On 12/07/2017 08:58 PM, Alexander Kanavin wrote:
On 12/07/2017 09:37 AM, Robert Yang wrote:
E.g.:
$ upgradehelper.py less strace bash git
The commit is removed when failed, and kept when succeed, but it wo
Hi Alexander,
Thanks for the quick reply.
On 12/07/2017 08:58 PM, Alexander Kanavin wrote:
On 12/07/2017 09:37 AM, Robert Yang wrote:
E.g.:
$ upgradehelper.py less strace bash git
The commit is removed when failed, and kept when succeed, but it would be
removed when next recipe runs, so only
On 12/07/2017 09:37 AM, Robert Yang wrote:
E.g.:
$ upgradehelper.py less strace bash git
The commit is removed when failed, and kept when succeed, but it would be
removed when next recipe runs, so only run clean_repo once can keep the commit,
which is helpful for the user.
I have removed the l
E.g.:
$ upgradehelper.py less strace bash git
The commit is removed when failed, and kept when succeed, but it would be
removed when next recipe runs, so only run clean_repo once can keep the commit,
which is helpful for the user.
Signed-off-by: Robert Yang
---
upgradehelper.py | 12 +++
13 matches
Mail list logo
