Hi @rel_0477, I just happen to check right when this came in. Glad to hear it is working again! Was it the local cache? Cargo has a pretty aggressive cache for both good and bad packages. Thanks, Rich

Hi @kc_2466 , The message "Feed-scoped Privileges are not available in ProGet Free Edition. You can still add them, but they will apply to all feeds." should be displayed when you add a privilege, but it's probably easy to miss. I'm not sure if we show it after that. As for Personal API Keys, you can create them as an admin, but non-admin users can't create their own. It's a different page. Cheers, Steve

Hi @darren-sloper_5044, Great! Glad to hear you are up and running again! Thanks, Rich

There was in issue with Docker container initialization due to some of the updated startup code in ProGet 2025 - it's now been resolved, and if you pull the proget:25.0.1 it should work. Hope this helps!

Hi Carl, Would you mind sharing the startup command that you're using? Can't get it to work properly. Ty, Jeremy

@apxltd Thanks for the update. I really appreciate you taking the time The reason I was looking to see if you supported winget yet is that I was replacing my own machine and I like to rebuild our developer image as I do so. I build our image from a base Windows image that has current Windows. I then run the “winget install” scripts to install the common tool chain. I understand on your side it doesn’t seem like a workable solution, but I love it. Winget works as if I downloaded and installed all the installs manually. Then I can just run “winget upgrade” to see what needs to be upgraded. The main benefit is that the upgrade check works even if a developer or I install something without using winget to install it. This is because “winget upgrade” uses Windows installed apps (as seen in appwiz.cpl) for its check. I hope they cleanup the backend so you could look at this product again.

Hi @layfield_8963, We've added osx-arm64 as another target, and we'll start deploying that along with the other binaries. We'll probably push out a new release today or tomorrow. Thanks!

Hi @parthu-reddy , First, please note that IIS is no longer recommended for ProGet 2024 and it is not supported in ProGet 2025: https://docs.inedo.com/docs/installation/windows/web#iis As for request limits, there are none. And it's not really a question that we can answer - a request can be anything from serving a cached image to doing a query with "chained connectors" that has to do a lot of network activity. It really depends on the types of feeds, configuration, etc. But a good "rule of thumb" is that 50-100 simultaneous connections will start to strain a server, and 10x that very likely be difficult to use. Hope that helps, Steve

Hi Rich, I really appreciate you looking into it and confirming the issue so quickly. It's great to know a ticket is already in the works. I'll keep an eye out for the fix in ProGet 2024.39. Thanks again for your help! – Matthias

Hi @parthu-reddy , Nothing to worry about - there are a few ways this can happen, and unless it's happening a lot and/or causing problems with your end-users / pipelines / etc., you can ignore the message. -- Dean

Hi @michal-roszak_0767 , I'm afraid Feed Groups are not currently supported in the Feed Management API or pgutil feeds commands. We are considering rewriting/refactoring the API later this year, so I've added this to the notes to consider for that. Thanks, Steve

@dimas thanks for that! We're currently studying/monitoring the performance for public mirroring, and one "concerning" thing I recently saw was a sqllite3 index file explode in file size. We don't know how that happened, but suspect it might have to do with some "aggressive" testing / request cancellation. Let us know if you spot anything: https://forums.inedo.com/topic/5410/debian-feed-mirror-performance

Hey @dimas , Ah, that makes sense. Looking at the manifest files, they have the same Identity@Id (which is what ProGet uses for the Package Name) but a different Identity@TargetPlatform (which must be new-ish): <Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/> <Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/> We could probably figure something out in ProGet, but it's not trivial when it comes time to changing how we identify Package Names. Can you try editing the manfiest file inside the vsix archive, and seeing if that works for your use case? So basically: <Identity Language="en-US" Id="python-win32-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/> <Identity Language="en-US" Id="python-linux-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/> Not quite sure if that would work, but figure it's worth a try. Thanks, Alex

To share with the community some things learned from a private support ticket -- There's currently a defect in the logic where if no packages were downloaded/uploaded to a debian type feed, the in-memory cache is never started. This leads to very long runtimes when running apt update since the response times for the /Release and /InRelease endpoints (from our experience) are at best 1 minute, at worst 10 minutes. The workaround support gave was to manually download a package via http before attempting to use apt. From our experience, this doesn't persist overnight, so it would basically need done daily and truly is counterintuitive to having a package manager like apt.

Hi @dean-houston Thank you for the ultra-quick response. Disabling that feature did indeed provide a workaround solution and currently testing is back on track. Thanks again Darren

Hi @layfield_8963, Looks like this was just a simple bug preventing output from being written when stdout has been redirected. It's now fixed in pgutil 2.1.1. Thanks for the update! -Greg

Your response gave me a hint -- i was just missing the relevant environmental variables from the OCI image. This is now resolved, thanks!

@michal-roszak_0767 sorry, this is definitely sub-optimal and needs work Basically, when you have API Key Hashing available, there's no way for the page to filter the incoming requests. So, all of the items are shown. It's not really a trivial to fix and requires us to rethink a bit how we are storing/logging this data. We can explore revisiting as part of ProGet 2026.

@steviecoaster the Native API should provide access to all of those procs FYI

Hi @caterina, Thanks for bringing this to our attention. I have created a ticket, PG-2990, to track the fix and it should be released in the next maintenance release on June 13th. Thanks, Rich