@henrique.tx - Here is the new topic I’m creating. We are using Verdin SOM, imx8mp. No kernel or uboot customization at this time, using Torizon Core as is.
It seems, “meta-toradex-nxp 6.4.3.p1.4” is being fetched and built from “linux-imx - i.MX Linux kernel” URL and this URL is there but not working at all.
meta-freescale has other community recipe for kernel-module to build GPU libs, however we could not find any way to override this recipe to use that community BB recipe.
The URL seems perfectly fine to me when I click on it. Also we do builds of our images every night and there hasn’t been any issues related to fetching this source.
Is it possible it was just a temporary issue or a network issue on your end?
@jeremias.tx - We have tried to do_fetch on this recipe from all kind of ISP that we have here in colorado. Most of us use Xfinity, AT&T, Centrylink etc. This link not at all working for us.
Does your nightly builds from clean start or just an incremental build? If it is incremental then Yocto download directory already has those tar balls from where Yocto build this recipe.
@jeremias.tx - We just quickly tried connecting to tier 1 VPN server to Germany and we are able to navigate this URL on browser as well as clone via CLI. It is slow cloning.
Not sure why this URL is having issue with USA DNS servers, but can toradex think of adding some mirror in future release to avoid this issues.
We are hoping for other solution to bypass this link to something else that provides this recipe a successful ‘do_fetch’
I did some further testing and your comment made me realize that when I was testing access to that URL I was connected to the Toradex VPN at the time.
I tried my tests again, disconnected to the VPN this time. Now I’m seeing what your describing. I’m U.S based as well and when I try to access this URL with a web browser, fails with bad gateway. Our test builds are based in Europe, so this is probably why the issue hasn’t been noticed by us.
Toradex doesn’t control this source repository so there’s nothing we can do immediately here. But, let me report this internally and see if there’s something that can be done.
As of now it seems like other regions may not be affected, at least the other regions where Toradex operates. Still seeing what can be done.
For the time being one idea for a workaround would be to use a VPN to clone this repo. Then mirror it to another location, like Github for example. Then modify or append the kernel-module-imx-gpu-viv recipe to point to this mirrored repo instead.
@jeremias.tx - We are doing the same currently. This repo is huge ~5 GB. It would be nice if Toradex does fork it on your Github and change your BSP to use that link so that it works out of box for your customers.
It would be nice if Toradex does fork it on your Github and change your BSP to use that link so that it works out of box for your customers.
It would be very unlikely we would do this. This repository is not owned/controlled/maintained by Toradex. By creating a fork we’d be taking ownership of this fork, with code that is not ours. The best we can do is notify the owners of this repo that there’s connection issues here.
In the meantime we just have to workaround this unfortunately.