iotedge-cli and iotedge-daemon are preventing us from build offline

[manszigher]

Describe the bug When trying to build an offline build and making use of BB_NO_NETWORK the iot-edge recipes will fail. We have a local source mirror so it should fetch any of the SRC_URI from there but it dose not my guess is that the reason is that both the daemon and cli recipe depends on some other repos

    git://github.com/Azure/hyperlocal-windows;protocol=https;branch=main;name=hyperlocal-windows;destsuffix=hyperlocal-windows \
    git://github.com/Azure/mio-uds-windows.git;protocol=https;branch=main;name=mio-uds-windows;destsuffix=mio-uds-windows \
    git://github.com/Azure/tokio-uds-windows.git;protocol=https;branch=main;name=tokio-uds-windows;destsuffix=tokio-uds-windows \

and that AUTOREV is used.

SRCREV_FORMAT .= "_hyperlocal-windows"
SRCREV_hyperlocal-windows = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/hyperlocal-windows"
SRCREV_FORMAT .= "_mio-uds-windows"
SRCREV_mio-uds-windows = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/mio-uds-windows"
SRCREV_FORMAT .= "_tokio-uds-windows"
SRCREV_tokio-uds-windows = "${AUTOREV}"
EXTRA_OECARGO_PATHS += "${WORKDIR}/tokio-uds-windows"

resulting in that it will always try and fetch it from an external source. We get the following error

ERROR: iotedge-cli-1.0.10-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command git -c core.fsyncobjectfiles=0 ls-remote https://github.com/Azure/hyperlocal-windows  (for url https://github.com/Azure/hyperlocal-windows)
ERROR: iotedge-cli-1.0.10-r0 do_fetch: Function failed: base_do_fetch

We can see in the DL_DIR that the packages that are causing the problems are always fetched instead of just setup as a link pointing to the SOURCE_MIRROR location

lrwxrwxrwx  1 ext ext     115 Mar  1 10:46 git2_anongit.freedesktop.org.pkg-config.tar.gz -> /cache/sources/git2_anongit.freedesktop.org.pkg-config.tar.gz
-rw-r--r--  1 ext ext   25361 Mar  1 10:56 git2_github.com.Azure.hyperlocal-windows.tar.gz
-rw-r--r--  1 ext ext       0 Mar  1 10:56 git2_github.com.Azure.hyperlocal-windows.tar.gz.done
-rw-r--r--  1 ext ext   99160 Mar  1 10:56 git2_github.com.Azure.mio-uds-windows.git.tar.gz
-rw-r--r--  1 ext ext       0 Mar  1 10:56 git2_github.com.Azure.mio-uds-windows.git.tar.gz.done
-rw-r--r--  1 ext ext   22635 Mar  1 10:56 git2_github.com.Azure.tokio-uds-windows.git.tar.gz
-rw-r--r--  1 ext ext       0 Mar  1 10:56 git2_github.com.Azure.tokio-uds-windows.git.tar.gz.done
lrwxrwxrwx  1 ext ext     114 Mar  1 10:46 git2_github.com.besser82.libxcrypt.git.tar.gz -> /cache/sources/git2_github.com.besser82.libxcrypt.git.tar.gz
lrwxrwxrwx  1 ext ext     123 Mar  1 10:46 git2_github.com.cryptodev-linux.cryptodev-linux.tar.gz -> /cache/sources/git2_github.com.cryptodev-linux.cryptodev-linux.tar.gz
lrwxrwxrwx  1 ext ext     105 Mar  1 10:46 git2_github.com.file.file.git.tar.gz -> /cache/sources/git2_github.com.file.file.git.tar.gz
lrwxrwxrwx  1 ext ext     111 Mar  1 10:46 git2_github.com.libgit2.libgit2.git.tar.gz -> /cache/sources/git2_github.com.libgit2.libgit2.git.tar.gz

To Reproduce Steps to reproduce the behavior:

1. Follow the offline build
2. Make sure you have BB_NO_NETWORK set to 1
3. Make sure you have a local SOURCE_MIRROR_URL e.g SOURCE_MIRROR_URL ?= "file:///cache/sources\"
4. Run bitbake -c fetch iotedge-cli
5. See error

Expected behavior I would have expected that the fetch task would use the SOURCE_MIRROR and would have found the necessary sources in there.

Logs If applicable, add logs to help explain your problem.

Build System (please complete the following information):

• OS: Ubuntu
• Version 20.04

Target System (please complete the following information):

• OS: GNU/Linux
• Version Na

Additional context I suspect it has something todo with the usage of AUTOREV but I am not sure. But I do think it is bad practice to use AUTOREV unless you absolutely must. I don't think AUTOREV is needed in this case since we have a versioned recipe. Specifying a sha would be a better solution in my opinion. I have tried setting the SRCREV to a sha and based on my tests I think it works. I can push a change for this but I would like to know if I have missed something.

[darobs]

Hi @manszigher - I just merged PR #79 that should address this. Please try this out and let me know.

Thanks!

[manszigher]

Hi thanks,

I will try it out but would that again just end up with taking the latest from main? I think it would make more sense to pick a sha. I can see when I am building that cargo is actually trying to get a specific sha from the project so not really sure why the recipe is not just specifying the sha we need from the start.

[darobs]

Please check out the 1.1.11 recipe changes. (PR #82). I was able to successfully build with these changes.