Hi @mayorovp_3701 , Thanks for confirming; we can will try to get this fixed in the next maintenance release via PG-3139 -- the underlying issue is most likely a race condition on that trigger I mentioned, so we're going to fix it by adding an advisory lock. It will not remove the duplicate content, but in theory deleting the image will. Thanks, Alana

Hi Alana, thanks, great to hear you are working on this and it is also being an improvement. :) Waiting for the update then and wishing a good start into the week, Frank

@felfert I saw the set-up first-hand, though I forgot what files were being edited, a .repo file I think. But the final setup is something like... [docker-ce-stable] name=Docker CE Stable - $basearch baseurl=https://download.docker.com/linux/rhel/$releasever/$basearch/stable enabled=1 gpgcheck=1 gpgkey={put the asset download url here, e.g. https://proget/endpoints/...} ... I know basically nothing about rpm so not sure if that helps at all

Hi @pawel-ostrowski_5669, Actually the version you're using (2025.8) has a known regression relating these PackageIds that we already fixed via PG-3097. I didn't realize it until you told me the version and I found that issue. Anyway please try latest version of ProGet 2025, it should work. Thanks, Alana

ok thanks for looking in to this. fyi: I think I found out what kind of feed ist used. It seemed to be a Chocolatey Simple Server https://github.com/chocolatey-community/simple-server/tree/master So it is V2 API based, but with some chocolatey customizations. This project seems to be deprecated by the chocolatey team.

Hi @fabrice-mejean , It's no longer possible to query this information from the database. As you've noticed, ProGet now uses a version range (i.e. AffectedVersions_Text ) to determine whether a package is vulnerable or not. So instead of 4.2.3 it's now 4.2.3-4.2.8 or [4.2.*) or something like that. Unfortunately it's not practical/feasible to parse this information unless you were to rewrite a substantial amount of ecosystem-specific parsing logic - this would be basically impossible to do in a SQL query. Instead, you'll need to use the upcoming pgutil packages meatdata command to see what vulnerabilities a particular packages has. You can also use Notifiers to address newly-discovered vulnerabilities. Thanks, Alana

Hi @koksime-yap_5909 , Not necessarily - it really depends on the API query. If the query is like "give me a list of all versions of MyPackage", then ProGet will need to aggregate local packages and connector packages to produce that list. If the query is "give me the metadata for MyPackage-1.3.1", then the first source that returns a result is used. In practice, NuGet asks for "all versions" a lot. So you'll get a lot of queries. Thanks, Alana

@james-woods_8996 we haven't released the extension yet, so it won't be in any builds of the product. We are waiting on someone to test/verify that it works

Hi @philippe-camelio_3885, Can you clarify what you've tried to date, and the issues you've faced? You can silently install the Inedo Agent, or even use a Manual Installation process if you'd prefer. Ultimately it's a standard Windows service, and you can change the account from LOCAL SYSTEM (which we recommend, by the way) to another account using sc.exe or other tools. Thanks, Alana

Hi @koksime-yap_5909 , Docker registry import from Sona, JFrog, and other ProGEt instances is coming soon via PG-3128 - we anticipate that in the next maintenance release. As for Assets, I'm afraid we don't have any support for that planned in the near future - it's relatively easy to write a script that "extracts" them - if you could extract it to a ProGet drop path, then they'll be imported that way. https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import-with-droppath -- Dean

Hi @tobe-burce_3659 , We do not support deleting or modifying any of the contents under the program directory; they will simply return when you upgrade and it may cause other problems. Instead, please create an exception; we are aware of the vulnerabilities in libraries that Postgresql uses and can assure you that they are false positives and will have no impact on ProGet... even if you were to be using PostgreSQL. Using virus/malware tools to scan/monitor ProGet's operation causes lots of problems, as these tools interfere with file operations and cause big headaches. Thanks, Alana

I had the same issue but it didn't update on startup so I ran this: cd /usr/local/proget/service/ ./proget upgradedb

Hi, Yes from my understanding you got it right. It's still very young. It's about storing a json "package" or text. In the json you can have a config for an url for a remote MCP server or a package that you can run on your computer to be a local MCP server (only from official repo for now). Maybe in the futur if this kind of registry can validate private package it could be nice to flag a package already in inedo to make it available in the MCP registry. Exemple : An internal team create an npm package for a MCP server or a docker package In proget I can have a MCP Registry with all kind of MCP server and for our own package we can just check an option on the package in proget to have it in the registry. Regards, Frédéric

Hi @fabrice-mejean , I definitely understand where you're coming from.... both commands basically work off the assets file, which is generated at build time. But your workflow is not common... the standard for SBOM generation is post-build. Doing it pre-build checking requires that packages.lock.json is used, which not many use... it's hard for us to advocate this workflow when most users don't care about saving time in this stage. I know we could add a "switch" or something to pgutil, but we learned "the hard way" that adding lots of complex alternative/branching paths to pgscan made for very difficult to maintain/understand code, so we want to keep the utility as simple as possible. Thanks, Alana

Hi @layfield_8963 , Thanks that makes sense -- since you've already got a personal repo going, I think it makes sense to stick with that for now. If other users are interested, we can explore it. We publish pgutil pretty regularly, so we'd need to automate updating that repository and that's just one more script t write and one more thing to break later :) Thanks, Alana

Thank you

Hi @it_9582 , This is a known issue / UI quirk with Conan packages, and hopefully should only impact that one page in the UI. To be honest I don't quite get the issue, but it has something to do with the fact that a Conan package is actually "set of packages that share a name and version". Each package in the set can define its own license file. The particular page was never really designed for "package sets" so the display is a little weird. It's a nontrivial effort to fix and would obviously impact all other package types, so it's not a priority at the moment. We would love to redo the UI at some point, s I think it'd mkae sense to do then. Thanks, Alana

Yeah, will do. I'll give it another try. Thanks Mickey