@manuel.riezebosch_8638 the purl argument was never actually read, so you could have really put anything in there :)

It was just one of those docs error; many other api endpoints will use a purl argument

And you're right... all the other package types have metadata inside the package, so that's what's read. Some require a file name, but Debian is an outlier in that it requires a distribution argument as well.

Hi @manuel-riezebosch_8638 ,

It looks like the HTTP Endpoint documentation for the pgutil packages upload command was not accurate. A purl is not used here. I've updated the docs as follows...

---

To upload a package, simply PUT to the URL with a feed name, an appropriate API Key and a package in either ZIP, JAR or TAR format depending on the value of the Content-Type header.

PUT /api/packages/«feed-name»/upload[/«package-file-name»]

The «package-file-name» part of the URL is only required for the PyPI and RPM feed types, while Debian feeds will require a distribution argument and an optional component. See the corresponding upload package method on ProGetClient.cs for the most accurate and up-to-date pgutil and HTTP endpoint argument mapping.

---

Hope that helps!

-- Dean

Hi @Nils-Nilsson ,

It's not really possible to "send a notification" without all the context (like Package Version, Name, etc.), but there is a relatively easy way to test that notifications are being sent (i.e. when you add a package).

If you configure a Email Notifier, you can check off the "Add notification in ProGet". You can enter a "fake email" or not even configure SMTP settings.

When you do that, it will still add a notification to ProGet (under Admin > Notifications) with the same body as the email.

-- Dean

Hi @certificatemanager_4002,

I'm not sure I totally understand the question :)

The ConnectionString property is marked as encrypted, which means that ProGet's Encryption Key will be used to store it to the database as encrypted, and obviously decrypt it.

But this should happen automatic, when using the API or UI to save the settings.

-- Dean

Hi @ybaskar-temp_3339,

Going off of memory here (this was like 10 years ago), but I believe that BuildMaster v5 would hide legacy options unless there was already legacy data. Since there's no legacy plans there's no button.

However, it still should be possible if you can find the url of the page to navigate to. I would check other apps for that option, inspect the url, and just replace it with your applications Id.

Let us know if that works!

-- Dean

@pg_user_8607 very cool, great practical use of the new ".cs scripts" type applications! I think this could make a nice blog post... I'll point this to our technical writers!

Hi @devops_8569 ,

I'm afraid this is a known limitation issue with Maven versions in ProGet for now.

Long story short, ProGet followed these versioning specifications:
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

However, some packages did not follow those specifications but instead relied on undocumented quirks (bugs?) in the Maven version parsing. These are now somewhat documented: https://maven.apache.org/pom.html#version-order-specification

It'd be nice to fix, but it would require a risky, non-trivial rewrite of our Maven version parsing to solve this. So far as we can tell, the only consequence is that a small number of vulnerabilities yield false positives. So, it's not a priority.

In ProGet 2026, we are substantially changing vulnerability management so it's likely these false positives won't be an issue anymore. For example, PGV-2314320 would be rated as a PVRS Category 2 for most environments.

We'll evaluate / explore this after getting feedback from users in ProGet 2026, and whether they think it's worth us investing the time/risk to address this limitation.

-- Dean

Hi @parthu-reddy ,

Thanks for the additional information. Thinking about it further, I suspect this was a temporary network outage. It could have been DNS related, or who knows what.

As for your configuration...

5000 is definitely too high; set this towards 100-500 max. If you're working on a load-balanced cluster, this should be done at the load balancer instead.

I was incorrect about api.nuget.org, that is also used by the V3 API. I thought it was only V2. So please disregard.

It's unlikely metadata caching will help, but you could try it. That's a relatively short-lived cache meant for traffic bursts, and it's not really going to help with a network outage.

-- Dean

Hi @parthu-reddy,

Thanks for the detailed investigation notes. From what you've described, the behavior doesn't appear to be related to SQL Server locking. It's most certainly related to blocking/waiting on the 200+ outgoing connections to receive a response from api.nuget.org.

If api.nuget.org is running slow, then ProGet will run slow. There's really no way around this when you use connectors, as ProGet is effectively forwarding client requests.

Most likely, someone or some build server is making legacy/V2 NuGet API requests (they look like ODATA/SQL queries on the url), and those are being forwarded. The V3 requests are just JSON files.

-- Dean

Hi @0xFFFFFFFF,

Thanks for the detailed write-up and explanation.

It looks trivial to add size and upload-time. Adding versions is probably simple, assuming it's just an array of distinct version numbers (we already have all the "packages" in context).

It's probably fine, but just to be safe we will do this in ProGet 2026, given some of the subtle behavioral changes you mentioned ("tools like uv to make use of heuristics to speed up downloads"). For someone with an overloaded server, that might "put it over the edge".

ProGet 2026 may be ready by the end of the month, so it's not so far away.

-- Dean

Hi @Nils-Nilsson ,

Thanks for the bug report; it seems to issue is on the "view" page, and it's mistakenly editing the wrong data.

PG-3258 will fix this in the next maintenance release (April 17), but a prerelease is now available (inedo/proget:25.0.26-ci.6) if you'd like to try it.

-- Dean

@rcpa0 thanks for letting us know; we'll try to fix this next time we make some changes to pgutil it should only print "Version is not a valid semantic version." or something

Hi @geraldizo_0690 , unfortunately we didn't get a chance to review this for the last maintenance release, but it'll be in the next one (April 17) via PG-3257. It's also available via prerelease if you'd like (inedo/proget:25.0.26-ci.5)

-- Dean

Hi @davi-morris_9177 ,

I'm afraid this behavior is expected because kotlin-stdlib-2.3.20.jar is not in the downloaded index file. There's is no file-listing API, which means there's no way to know what should be there otherwise.

The Maven client downloads "blindly downloads" some files, and "silently accepts" a 404 for other files. When it's downloaded (cached), then ProGet knows about it. So, you really need to download the artifacts first if you want to make a curated feed I'm afraid.

-- Dean

Hi @certificatemanager_4002 ,

Check out our Licenses for Non-production / Testing Environments for the full details.

But if its a short-term migration testing scenario, then using an existing or trial key is fine. For a long-term environment, a separate license is required.

-- Dean

Hi @adoran_4131 ,

Keep in mind that ProGet and Artifactory work differently; Artifactory is basically a "file server" and is just does "blind proxying" of HTTP requests. That's why it doesn't matter what URLs you put in. ProGet, on the other hand, is a package server, and will index the remote repository first. That's where things are failing right now.

It's failing because the index file is not being found based on the input. This is what a Debian repository is supposed to look like:

dists/
    {distribution-name}/
        Release
        Release.gpg
        main/
            binary-amd64/
                Packages
                …
pool/
    main/ …

So, the distribution-name is incorrect. I thought it might be binary based on the instructions, but these URLs are both a 404:

https://pkg.jenkins.io/debian-stable/dists/binary/Release
https://pkg.jenkins.io/debian-stable/dists/binary/InRelease

So, it must be something else. It's whatever apt is sending by default, I guess?

Anyway, if you can find what distribution it should be, then it will work. Perhaps consider just doing something like this:

sudo apt update -o Debug::Acquire::http=true

That will show you the HTTP requests being made, and you can see exactly the URL for the Release file, which you can then use to reverse-engineer the distribution name.

Let us know what you find!

Hope that helps,
Steve

Hi @parthu-reddy ,

Sorry on the slow reply, check out the link I sent you via t icket! Just let us know when you upload the files and we'll talke a look then!

Thanks.

-- Dean

Hi @scusson_9923 ,

Can you share the OtterScript where you tried the try/catch ? Perhasp that's just something we can more easily fix.

-- Dean

Hi @tyler_5201,

The UI package search is pretty basic, so it's not going to look through those metadata properties. They are something you could obviously search/find through the API.

Depending on what you're trying to do, we do have a Whitelabel feature that makes the UI a lot easier to consume for end-users:

• https://docs.inedo.com/docs/proget/administration/whitelabel
• https://inedo.com/proget/case-studies/salient

In particular, the "Tile View" on Universal Packages may help. But it's not very popular and is something we work closely with our users on, so let us know if that's of interest.

-- Dean

Hi @tyan-yin_2201,

It looks like it's only supported on FeedCommand -- I'm not entirely sure why. It appears to be settable when calling the HTTP API however.

We ought to be able to add it relatively easy, but can you share the use case? It's also good to know why someone would want to explicitly set an api key from command line (most tools don't seem to support this).

-- Dean