SRCREV should be the actual commit hash that matches the tag, then
do_unpack will not do git ls-remote. Tags can, and do move around.
Alex
On Tue, 30 Jun 2020 at 19:24, John Klug wrote:
> We typically use tags to match PV and name our recipes NAME_TAG.bb
>
> Recipe name:
>
> dhq-client_0.39.bb
We typically use tags to match PV and name our recipes NAME_TAG.bb
Recipe name:
dhq-client_0.39.bb
from bitbake -e dhq-client output:
# pre-expansion value:
# "${PN}-${PV}"
P="dhq-client-0.39"
In recipe:
SRCREV = "${PV}"
SRC_URI =
"git://g...@gitlab.multitech.net/devicehq/mAPI-dhq-client.
This happens if the recipe does not specify the exact revision hash to use
in SRCREV. If it says "use latest revision" or "use this tag", then
bitbake will do ls-remote on the original repo to resolve those to
up-to-date revisions, which is not unreasonable.
What does the recipe look like?
Alex
Hi John,
On Tue, Jun 30, 2020 at 04:45:32AM +, John Klug wrote:
>
> a:
>
> (fetch was already run successfully while connected with a VPN).
>
> VPN then shut down.
>
> $ bitbake -c unpack dhq-client
>
> ...
> NOTE: Executing RunQueue Tasks
> ERROR: dhq-client-0.32-r11 do_unpac
a:
(fetch was already run successfully while connected with a VPN).
VPN then shut down.
$ bitbake -c unpack dhq-client
...
NOTE: Executing RunQueue Tasks
ERROR: dhq-client-0.32-r11 do_unpack: Fetcher failure: Fetch command export
DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-
It would help if you can:
a) provide log.do_unpack that shows that network access is indeed happening;
b) demonstrate the behavior with oe-core master, as morty is soon eligible
for retro computing museum, and hardly anyone wants to look into that :)
Alex
On Sun, 28 Jun 2020 at 19:27, John Klug
Recently it has come to my attention that in morty, and maybe later, do_unpack
for git does not use the downloads directory, and attempts to contact the git
server.
This is unfortunate, as we often do bitbake -c fetchall and give tarballs of
our workspace to customers, thinking it would save so
