Hi Andrei,
On 07/09/2015 11:13 PM, Andrei Gherzan wrote:
Finally I hop on to this discussion too.
On Mon, Jul 6, 2015 at 12:58 PM, Paul Eggleton
paul.eggle...@linux.intel.com mailto:paul.eggle...@linux.intel.com
wrote:
On Monday 06 July 2015 12:48:50 Nikolay Dimitrov wrote:
One issue
Finally I hop on to this discussion too.
On Mon, Jul 6, 2015 at 12:58 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Monday 06 July 2015 12:48:50 Nikolay Dimitrov wrote:
One issue with the regularly changing tarball checksums is that people
start to get used to thes changes
* Clemens Lang clemens.l...@bmw-carit.de [150706 07:24]:
On Fri, Jun 26, 2015 at 09:31:14AM +0100, Burton, Ross wrote:
Github also can and will regenerate these tarballs whenever it feels
like it, so you'll need to periodically update the checksums.
Obviously as existing developers will
Hi guys,
One issue with the regularly changing tarball checksums is that people
start to get used to thes changes (e.g. everything looks like false
positive). Currently the tarball checksums and SCM revisions are
probably the most important tool for builds traceability. If we get
used to think
On Monday 06 July 2015 12:48:50 Nikolay Dimitrov wrote:
One issue with the regularly changing tarball checksums is that people
start to get used to thes changes (e.g. everything looks like false
positive). Currently the tarball checksums and SCM revisions are
probably the most important tool
On 06/26/2015 04:16 PM, Jon Szymaniak wrote:
On Fri, Jun 26, 2015 at 4:31 AM, Burton, Ross ross.bur...@intel.com
mailto:ross.bur...@intel.com wrote:
On 26 June 2015 at 05:16, Jon Szymaniak jon.szyman...@gmail.com
mailto:jon.szyman...@gmail.com wrote:
GitHub provides this
Hello,
On Fri, Jun 26, 2015 at 09:31:14AM +0100, Burton, Ross wrote:
Github also can and will regenerate these tarballs whenever it feels
like it, so you'll need to periodically update the checksums.
Obviously as existing developers will tend to have the tarballs cached
locally, it can be a
On 26 June 2015 at 05:16, Jon Szymaniak jon.szyman...@gmail.com wrote:
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than fetching the entire git repository.
Github also can and will regenerate these
On 26 June 2015 at 15:16, Jon Szymaniak jon.szyman...@gmail.com wrote:
I'm open to other suggestions as well, as this was just a first stab at
it. I've been seeing that cloning this git repo containing binary firmware
blobs takes an absurd amount of time, if it even finishes at all
On Fri, Jun 26, 2015 at 10:19 AM, Burton, Ross ross.bur...@intel.com
wrote:
On 26 June 2015 at 15:16, Jon Szymaniak jon.szyman...@gmail.com wrote:
I'm open to other suggestions as well, as this was just a first stab at
it. I've been seeing that cloning this git repo containing binary
On Fri, Jun 26, 2015 at 4:31 AM, Burton, Ross ross.bur...@intel.com wrote:
On 26 June 2015 at 05:16, Jon Szymaniak jon.szyman...@gmail.com wrote:
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than
On 26 June 2015 at 15:42, Jon Szymaniak jon.szyman...@gmail.com wrote:
Back to the git depth point... why is --depth 1 not the default for all
cases? Could anyone elaborate on some use cases where we'd actually want
the entire history for builds?
I'm sure I've been told that it's not as
On 2015-06-26 02:31, Burton, Ross wrote:
On 26 June 2015 at 05:16, Jon Szymaniak jon.szyman...@gmail.com
mailto:jon.szyman...@gmail.com wrote:
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than
On 26 June 2015 at 10:07, Gary Thomas g...@mlbassoc.com wrote:
Is that something that can be in the recipe, or is this ability
something that needs to be added to the bitbake/OE-core infrastructure?
The fetcher needs to be patched.
Ross
--
___
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than fetching the entire git repository.
This resolves some do_fetch() failures I've seen for bcm2835-bootfiles
in which the clone operation takes a very long
15 matches
Mail list logo
