All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Trevor Woerner <twoerner@gmail.com>
Cc: bitbake-devel <bitbake-devel@lists.openembedded.org>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Checksum failure encountered with download
Date: Fri, 12 Apr 2013 22:37:46 +0200	[thread overview]
Message-ID: <20130412203746.GW2477@jama> (raw)
In-Reply-To: <CAHUNapRzKJrofFbKX2=5rJZJxSdo+S+5c38GHkp0J8Mhz=C+sw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Fri, Apr 12, 2013 at 03:44:41PM -0400, Trevor Woerner wrote:
> Sorry for not noticing this sooner.
> 
> On Thu, Apr 11, 2013 at 9:30 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > My proposal is to add md5sum of downloaded file to ChecksumError and
> > rename it to <file>.<md5sum> in "if isinstance(e, ChecksumError):"
> 
> Would it be possible to make this behaviour configurable for those who
> might be concerned about disk space? Or perhaps while renaming and
> saving it, also move it into the $TMPDIR directory and/or tie this
> feature in with rm_work?
> 
> I'm just thinking that over time one's DL_DIR could potentially become
> rather cluttered with lots of failed downloads. Only some people would
> be interested in seeing the failures and the rest would have to remove
> them manually. I'm also thinking of the scenario where the DL_DIR is
> shared/sync'ed among a group of people/computers; that could add up to
> quite a bit of data to share.

I can make it configurable, but I think that bad-checksums should be
only in few exceptional cases, while package upgrades are common.

That said 90% of my downloads directory are old versions I keep just to
be able to recreate old builds with upstream sources already gone and
now I've one renamed bad-checksum tarball from evas-1.7.6.1...

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Martin Jansa <martin.jansa@gmail.com>
To: Trevor Woerner <twoerner@gmail.com>
Cc: bitbake-devel <bitbake-devel@lists.openembedded.org>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [bitbake-devel] Checksum failure encountered with download
Date: Fri, 12 Apr 2013 22:37:46 +0200	[thread overview]
Message-ID: <20130412203746.GW2477@jama> (raw)
In-Reply-To: <CAHUNapRzKJrofFbKX2=5rJZJxSdo+S+5c38GHkp0J8Mhz=C+sw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Fri, Apr 12, 2013 at 03:44:41PM -0400, Trevor Woerner wrote:
> Sorry for not noticing this sooner.
> 
> On Thu, Apr 11, 2013 at 9:30 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > My proposal is to add md5sum of downloaded file to ChecksumError and
> > rename it to <file>.<md5sum> in "if isinstance(e, ChecksumError):"
> 
> Would it be possible to make this behaviour configurable for those who
> might be concerned about disk space? Or perhaps while renaming and
> saving it, also move it into the $TMPDIR directory and/or tie this
> feature in with rm_work?
> 
> I'm just thinking that over time one's DL_DIR could potentially become
> rather cluttered with lots of failed downloads. Only some people would
> be interested in seeing the failures and the rest would have to remove
> them manually. I'm also thinking of the scenario where the DL_DIR is
> shared/sync'ed among a group of people/computers; that could add up to
> quite a bit of data to share.

I can make it configurable, but I think that bad-checksums should be
only in few exceptional cases, while package upgrades are common.

That said 90% of my downloads directory are old versions I keep just to
be able to recreate old builds with upstream sources already gone and
now I've one renamed bad-checksum tarball from evas-1.7.6.1...

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  reply	other threads:[~2013-04-12 20:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 13:30 Checksum failure encountered with download Martin Jansa
2013-04-11 21:40 ` Richard Purdie
2013-04-11 21:40   ` [bitbake-devel] " Richard Purdie
2013-04-12 14:08 ` [PATCH] fetch2: rename file with bad checksum instead of removing it completely Martin Jansa
2013-04-12 19:44 ` Checksum failure encountered with download Trevor Woerner
2013-04-12 19:44   ` [bitbake-devel] " Trevor Woerner
2013-04-12 20:37   ` Martin Jansa [this message]
2013-04-12 20:37     ` Martin Jansa
2013-04-15 13:41     ` Richard Purdie
2013-04-15 13:41       ` [bitbake-devel] " Richard Purdie

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=20130412203746.GW2477@jama \
    --to=martin.jansa@gmail.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=twoerner@gmail.com \
    /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.