Hi Marc, Thanks for the note! That file is actually a sort of cross-platform way of storing symbolic links. BuildMaster also includes all the binaries needed for agents on both Windows and Linux, including .net runtimes for all three. In order to save space we deduplicate identical binaries from the agents. We use a simple json file instead of proper symlinks because we use the same file on Windows/Linux and it's easier this way. All the paths in the file have historically used Windows path separators due to how we generate it, and we convert those in BuildMaster at runtime to the proper format.... or at least we were supposed to. At some point there was a regression added that caused this to not happen when updating from Linux. Anyway, this will be fixed as BM-3981 in the next release :)

Hi @jfullmer_7346, Thanks for the detailed recreation steps on this! I was able to recreate the issue and created a ticket, PG-3018, to track the fix. This is expected to be fixed in ProGet 2025.2 on Friday of this week. Thanks, Rich

Thanks @rhessinger, that clarifies things, and I can move on. Best regards, Stefan

Hi @lukas-christel_6718, Sorry for the delay on this. We just pushed an updated pgutil that will now skip over any invalid versions. Thanks, Rich

Hi @m-karing_2439, It looks like this is a network-related issue: "Cannot determine the frame size or a corrupted frame was received." There are no changes in ProGet 2025 that would cause something like this, but it's possible that a firewall or something else is interfering with the communication. The executable name changed from ProGet.Service.exe to proget.exe, and we've seen some "anti-virus" tools require a new execption be made. No idea why it would work for PyPi, however. Hope that at least points in the right direction. Thanks, Steve

Yes - they are "self-connectors". We've now bought an externally signed certificate, as it seemed like the simpler option (the in house cert option was causing other issues too). However that hasn't resolved the issue with the self-connectors. However, I've just edited those connectors manually to use http rather than https, and that has resolved the issue. But It's not really an ideal solution. So it looks like from inside the docker container it's still not "trusting" the externally signed certificate.

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 @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 @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

@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

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