All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH v3] fetch2: implement progress support
Date: Mon, 11 Jul 2016 10:25:50 +1200	[thread overview]
Message-ID: <1552677.cH6Xo9A2Ac@peggleto-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <2108760.2DEpCLmkyV@peggleto-mobl.ger.corp.intel.com>

On Mon, 11 Jul 2016 10:23:30 Paul Eggleton wrote:
> On Wed, 06 Jul 2016 16:26:10 Paul Eggleton wrote:
> > Implement progress reporting support specifically for the fetchers. For
> > fetch tasks we don't necessarily know which fetcher will be used (we
> > might initially be fetching a git:// URI, but if we instead download a
> > mirror tarball we may fetch that over http using wget). These programs
> > also have different abilities as far as reporting progress goes (e.g.
> > wget gives us percentage complete and rate, git gives this some of the
> > time depending on what stage it's at). Additionally we filter out the
> > progress output before it makes it to the logs, in order to prevent the
> > logs filling up with junk.
> > 
> > At the moment this is only implemented for the wget and git fetchers
> > since they are the most commonly used (and svn doesn't seem to support
> > any kind of progress output, at least not without doing a relatively
> > expensive remote file listing first).
> > 
> > Line changes such as the ones you get in git's output as it progresses
> > don't make it to the log files, you only get the final state of the line
> > so the logs aren't filled with progress information that's useless after
> > the fact.
> > 
> > Part of the implementation for [YOCTO #5383].
> > 
> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> > ---
> > 
> > Changes since v2:
> >  * Use -v instead of --show-progress in the wget command line since the
> >  
> >    latter is only available with wget 1.16 and newer, and we still need
> >    to support distros that have older versions than that. This does
> >    override the default of -nv if present (which it will be via the
> >    FETCHCMD_wget set in bitbake.conf within OE), but the added verbosity
> >    is minimal since the progress information is filtered out of the logs
> >    by the progress handler.
> 
> So, you asked me to send this, but unfortunately it looks like you merged
> the old version - I guess I should send an additional patch now.

Wait a second - you didn't merge it at all, sorry my mistake.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2016-07-10 22:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 10:59 [PATCH v2 00/10] Support progress reporting Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 01/10] knotty: provide a symlink to the latest console log Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 02/10] knotty: import latest python-progressbar Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 03/10] lib: implement basic task progress support Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 04/10] lib/bb/progress: add MultiStageProgressReporter Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 05/10] fetch2: implement progress support Paul Eggleton
2016-07-06  4:26   ` [PATCH v3] " Paul Eggleton
2016-07-10 22:23     ` Paul Eggleton
2016-07-10 22:25       ` Paul Eggleton [this message]
2016-06-23 10:59 ` [PATCH v2 06/10] knotty: add code to support showing progress for sstate object querying Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 07/10] knotty: show task progress bar Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 08/10] knotty: add quiet output mode Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 09/10] runqueue: add ability to enforce that tasks are setscened Paul Eggleton
2016-06-23 10:59 ` [PATCH v2 10/10] runqueue: report progress for "Preparing RunQueue" step Paul Eggleton

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=1552677.cH6Xo9A2Ac@peggleto-mobl.ger.corp.intel.com \
    --to=paul.eggleton@linux.intel.com \
    --cc=bitbake-devel@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.