Retrieving List of Available Packages takes forever.

[ian.yeager]

When navigating to a system to view the available feeds it is taking forever to get past the spinning wheel and "Retrieving List of Available Packages" message, and once complete I get this message; 

    One or more feeds failed to update.
    Packages available from these feeds will not be shown.
    http://download.ni.com/support/nipkg/products/ni-package-manager/released
    http://download.ni.com/support/nipkg/products/ni-package-manager/eulas
    https://download.ni.com/support/nipkg/products/ni-s/ni-systemlink-client/19.0/released
    https://download.ni.com/support/nipkg/products/ni-s/ni-systemlink-client/19.0/released-critical

The only thing showing on the installed tab is;

    NI Package Manager

    NI SystemLink Client

    NI SystemLink File Client Runtime

    NI SystemLink Message Client Runtime

    NI SystemLink Tag Client Runtime

My guess is it's because these systems are production floor only and do not have access to the internet and are trying to get to some outside location to look for feeds. Is there any way to shut that off?

[GreyGrey]

Each system should try to take a look at the registered feeds when you pull up the Software tab. If the system is not connected to the internet, the feeds aren't really serving any purpose because they can't be reached. I would probably recommend removing the feeds that can't be reached. 

[ian.yeager]

How would we manage NI specific feeds, like the LabVIEW runtime then?

Perhaps I'm misunderstanding the intent of the feed. If I have an application that uses a number of NI feeds downloaded onto my server (LabVIEW Runtime, Switch Executive, etc...) and then deploy that feed to a client, is the intent that the client manages that feed from then on or does the server? Shouldn't the client only need to see the server, not the location of the feed?

[ian.yeager]

Also, it looks like the following two feeds cannot be removed from my system;

ni-package-manager-eulas

ni-package-manager-released

Thoughts?

[GreyGrey]

Feeds are collections of packages that are used to either download/install new software/drivers, or used to update existing software. With SystemLink, you have the ability to host feeds which can be used to deploy software to targets. The feeds that SystemLink hosts are located on the SystemLink machine (so not on the internet) which would allow targets connected to the SystemLink server to see them. If those targets that are connected to SystemLink do not have access to the internet, you don't really need to have any NI hosted feeds registered on them because they won't ever be able to access those feeds. However, if you are hosting the packages that are being installed to the target on your SystemLink Server, you probably would want those feeds registered because you may want to update them in the future.

The idea is that the whoever manages the server would manage the feeds that targets have registered. I'm not sure how the NI feeds are getting registered on the target. I think that for some NI software installation, the installation automatically registers the public feed for that software. If that's the case, you could either manually unregister the feed using the SystemLink Software view, or could use a NIPM CLI command to script the unregistering of those feeds.

Regarding your second question, the NI Package Manager doesn't allow you to unregister the NI Package Manager feeds from the UI. It seems that they also don't let SystemLink remove them. However, you can manually remove those feeds by editing/removing a file on the target machine. If you either remove or delete the text inside of the "ni-package-manager-released.ini" file located in the "C:\ProgramFiles\National Instruments\NI Package Manager\Settings" directory

[ian.yeager]

Brandon,

I mostly understand your answer, however, I'd like to try and clarify one thing. If I have Application A and I create a package for it, Package A, I can upload that package to the server and create a feed for it. Package A consists of the application and that application has dependencies, e.g. LabVIEW Run-Time, DAQmx Runtime, etc... What is the intent to manage those dependencies for stand-alone systemlink instances (non-internet connected). When building the package is there a way to include (not just require, but physically locate them with the application) those dependent packages, like I would with an installer? If not, is there a way to include the dependencies on the feed at the SystemLink server level without registering them back to ni.com? 

I'd like to deploy an application and it's dependencies to a group of non-internet connected clients from a server that is also not connected to the internet. These system's live on a production floor and would never have access to the outside world, however, I can remotely hit the server with a work PC and that PC also has access to the internet. 

[GreyGrey]

---

@ian.yeager wrote:

What is the intent to manage those dependencies for stand-alone systemlink instances (non-internet connected). When building the package is there a way to include (not just require, but physically locate them with the application) those dependent packages, like I would with an installer?

---

There is a way to deploy them with the package, however they won't be included inside of your package, and instead would be in their own packages, just in the same feed as your application package.To do this, you would just declare a dependency relationship to the packages that you are wanting to deploy along side your package. Usually when you declare something as a dependency, you also want those packages included in the same feed. So you would also need to add the packages for your dependency (drivers, etc.) to your SystemLink hosted feed. The relationships of your package ('Depends', 'Recommends', etc.) are set in the control file of the package. Those relationships are documented in the NIPM Manual. 

When those relationships are configured, and the package is located in the same feed as your package, when NIPM goes to install the package, it will see that there are dependencies, and it will attempt to find them in the systems registered feeds. Since we put them in the same feed as the package, it will find them and install them before installing your package. 

Via this workflow you would be able to add Packages to the SystemLink Server from ni.com hosted feeds from your internet connected computer, and they then would be used in the deployment of your application. Does this all make sense?

[ian.yeager]

Brandon,

It definitely makes sense, but as I attempt to work through it on my system I'm must be missing something. Perhaps it's because I'm not seeing a one to one relationship between a dependency listed in the package builder, and a package to add to the feed; e.g. "488.2 Runtime" is a dependency of our application, listed in package manager, however I'm not finding a package to add to the feed that's called "488.2 Runtime". Is there a video available that walks through this process, or would you be willing to perhaps have a quick Skype session to show me an example? 

[Trevor.H]

Is "NI-488.2" present on that list?

[navarf01]

Hello Trevor,

I came to this post because of the title "Retrieving List of Available Packages takes forever"

In our case we are working also with production clients that has no access to internet. Our Server do has some limited access to internet but for sure it can access to NI URLs.

The problem we have is that we will wait for the available list but we get a time out every time.

At the beginning we were thinking that maybe firewall configuration of clients could affect but after running some tests we don´t see a relation with firewall configuration.
Have you experienced this kind of problem before? Do you have any suggestion on what could we do to try to be able to update this list?

I hope my explanation is clear. Thanks in advance for any advice you could give us about this topic.