All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: "Niek Linnenbank" <nieklinnenbank@gmail.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Beniamino Galvani <b.galvani@gmail.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	Pavel.Dovgaluk@ispras.ru, Cleber Rosa <crosa@redhat.com>,
	Willian Rampazzo <willianr@redhat.com>
Subject: Re: [PATCH v2 1/2] tests/acceptance: replace unstable apt.armbian.com URLs for orangepi-pc, cubieboard
Date: Thu, 25 Feb 2021 00:10:21 +0100	[thread overview]
Message-ID: <6309e75e-2aa4-5bc1-66be-0b29f408f179@amsat.org> (raw)
In-Reply-To: <CAPan3WqXre=Rau4-jOSE2u=GGRO8hSKzuuWFSN4xP3wbpvQ-Dg@mail.gmail.com>

+Thomas/Daniel/Alex/Peter/Paolo/Stefan/Markus

On 2/24/21 9:02 PM, Niek Linnenbank wrote:
> Hi Philippe, Cleber,
> 
> On Wed, Feb 24, 2021 at 8:14 PM Cleber Rosa <crosa@redhat.com
> <mailto:crosa@redhat.com>> wrote:
> 
>     On Wed, Feb 24, 2021 at 10:12:10AM +0100, Philippe Mathieu-Daudé wrote:
>     > Hi Niek,
>     >
>     > On 2/23/21 11:53 PM, Niek Linnenbank wrote:
>     > > Currently the automated acceptance tests for the Orange Pi PC
>     and cubieboard
>     > > machines are disabled by default. The tests for both machines
>     require artifacts
>     > > that are stored on the apt.armbian.com <http://apt.armbian.com>
>     domain. Unfortunately, some of these artifacts
>     > > have been removed from apt.armbian.com <http://apt.armbian.com>
>     and it is uncertain whether more will be removed.
>     > >
>     > > This commit moves the artifacts previously stored on
>     apt.armbian.com <http://apt.armbian.com> to github
>     > > and retrieves them using the path: '/<machine>/<artifact>'.
>     > >
>     > > Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com
>     <mailto:nieklinnenbank@gmail.com>>
>     > > Reviewed-by: Willian Rampazzo <willianr@redhat.com
>     <mailto:willianr@redhat.com>>
>     > > Reviewed-by: Cleber Rosa <crosa@redhat.com
>     <mailto:crosa@redhat.com>>
...

>     Nope, and I'm having issues with those URLs.  For instance:
> 
>        $ curl -L
>     https://github.com/nieklinnenbank/QemuArtifacts/raw/master/cubieboard/linux-image-dev-sunxi_5.75_armhf.deb
>     <https://github.com/nieklinnenbank/QemuArtifacts/raw/master/cubieboard/linux-image-dev-sunxi_5.75_armhf.deb>
>        version https://git-lfs.github.com/spec/v1
>     <https://git-lfs.github.com/spec/v1>
>        oid
>     sha256:a4b765c851de76592f55023b1ff4104f7fd29bf90937e6054e0a64fdda56380b
>        size 20331524
> 
>     Looks like it has to do with GitHub's behavior wrt quota.
> 
> 
> Indeed. Just this morning I received an e-mail from github with the
> following text:
> 
> "[GitHub] Git LFS disabled for nieklinnenbank
> 
> Git LFS has been disabled on your personal account nieklinnenbank
> because you’ve exceeded your data plan by at least 150%.
> Please purchase additional data packs to cover your bandwidth and
> storage usage:
> 
>   https://github.com/account/billing/data/upgrade
> <https://github.com/account/billing/data/upgrade>
> 
> Current usage as of 24 Feb 2021 09:49AM UTC:
> 
>   Bandwidth: 1.55 GB / 1 GB (155%)
>   Storage: 0.48 GB / 1 GB (48%)"
>  
> I wasn't aware of it but it appears that Github has these quota's for
> the Large File Storage (LFS). I uploaded the files in the git LFS
> because single files are also limited to 100MiB each on the regular Git
> repositories.
> 
> With those strict limits, in my opinion Github isn't really a solution
> since the bandwidth limit will be reached very quickly. At least for the
> LFS part that is. I don't know yet if there is any limit for regular access.
> 
> My current ideas:
>   - we can try to splitup the larger files into sizes < 100MiB in order
> to use github regular storage. and then download each part to combine
> into the final image.
>     im not really in favour of this but it can work, if github doesnt
> have any other limit/quota. the cost is that we have to add more
> complexity to the acceptance test code.
>   - we can try to just update the URLs to armbian that are working now
> (with the risk of breaking again in the near future). Ive also found
> this link, which may be more stable:
>      https://archive.armbian.com/orangepipc/archive/
> <https://archive.armbian.com/orangepipc/archive/>
>   - or use the server that im hosting - and i don't mind to add the
> license files on it if needed (should be GPLv2 right?)
> 
> I'd be interested to hear your opinion and suggestions.
> 
> Kind regards,
> Niek

Some of the unpractical options I can think of...:

- do not contribute tests using binary blob
- do not allow test image >100 MiB
- contribute tests with sha1 of (big) image but say "if you want
  the test image contact me off-list" then when the contributor
  stop responding we remove the test
- have anyone setup its servers with tests source and images,
  without committing anything to the repository. Interested
  maintainers/testers are on their own.
- testing done behind the scene

TBH I'm a bit hopeless.

Regards,

Phil.


  reply	other threads:[~2021-02-24 23:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 22:53 [PATCH v2 0/2] Allwinner H3 fixes for EMAC and acceptance tests Niek Linnenbank
2021-02-23 22:53 ` [PATCH v2 1/2] tests/acceptance: replace unstable apt.armbian.com URLs for orangepi-pc, cubieboard Niek Linnenbank
2021-02-24  9:12   ` Philippe Mathieu-Daudé
2021-02-24 19:13     ` Cleber Rosa
2021-02-24 20:02       ` Niek Linnenbank
2021-02-24 23:10         ` Philippe Mathieu-Daudé [this message]
2021-02-25  5:22           ` Thomas Huth
2021-02-25  9:46         ` Daniel P. Berrangé
2021-02-25 19:39           ` Niek Linnenbank
2021-02-23 22:53 ` [PATCH v2 2/2] hw/net/allwinner-sun8i-emac: traverse transmit queue using TX_CUR_DESC register value Niek Linnenbank

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=6309e75e-2aa4-5bc1-66be-0b29f408f179@amsat.org \
    --to=f4bug@amsat.org \
    --cc=Pavel.Dovgaluk@ispras.ru \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=b.galvani@gmail.com \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=nieklinnenbank@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=willianr@redhat.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.