Posts made by dean-houston

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

Hi @udi-moshe_0021 ,

It looks like there's something wrong with your configuration file:
https://docs.inedo.com/docs/installation/configuration-files

It looks like there's a bad/missing PostgreSQL string in there. I don't know how that happened.

-- Dean

Hi @udi-moshe_0021 ,

If you can try it now, the installer should be published.

-- Dean

Hi @udi-moshe_0021 ,

I'm sorry I'm not really able to understand what the specific issue is based on your response. If you can share specific error messages or specific things you're seeing, we might be able to help.

Otherwise there are no known issues installing ProGet on Windows, and if you're having an issue it's almost always a security/antivirus tool that's interfering with modifying system configuration.

-- Dean

Hi @udi-moshe_0021,

If there was no error during installation, it's hard to say; perhaps something is going on with the Windows Service registry, or you need to refresh, or who knows.

I would try rebooting and then installing again.

There is no service for Postgres, just INEDOPROGETSVC

-- Dean

Hi @mayorovp_3701,

This is a bug you should definitely report to GitLab -- it's clearly required by the API and all other registries support it. Without that API defined, we have to "make guesses" based on undocumented conventions (i.e. /v3-flatcontainer/{id}), which causes headaches down the line. That's why there's an API contract :)

I don't know how/why it works with dotnet sdk -- perhaps it's using a different endpoint, or maybe it's not actually working and just going to NuGet.org. Whatever the case, it doesn't make sense for us to build workarounds for easily-fixable bugs on GitLab when other vendors seem to follow the API contract.

-- Dean

Hi @jw ,

Nice catch, we'll add pgutil builds delete and pgutil builds projects delete via PG-3189

You may be able to use pgutil builds create to archive a build (`--inactive), but I'm not sure. Either way, there's no way to flip it back, so we will update it.

The create command can also update, but it's not clear, so we will edit the help text to clarify.

-- Dean

Hi @m-lee_3921,

When specifying a package source, the package must be in the same feed; you could specify it using a URL however.

   {
    "virtualPath": "common/logo/logo.png",
    "source": { 
       "url": "http://proget/endpoints/customer-assets/content/ast-logo.png"
    }

Good point on the documentation; download-vpack is for the .vpack file only (i.e. manifest). I'll update it

-- Dean

@uel_2013 (I deleted my previous reply since I learned a few more details from a team member who talked with you already)

Given your team size, you'd definitely be better off upgrading (rethinking) your CI/CD processes when switching over to BuildMaster. As some users have told us, the Octopus Deploy way is like "trying to apply the SVN mindset in a Git world".

The main benefit to a small team is that it's a simplification/consolidation of build- and deployment tools, while also giving you a powerful platform and process. We're working on "codifying" this in an upcoming guide called Lean Platforms: Engineering & Orchestration.

You could likely get BuildMaster to work in a similar way (i.e. a "deployment script runner"), but you'll be "fighting against the current" and you would be missing out nearly all of the benefits. For example, we have different ways of handling multi-tenancy (e.g. depending on if you do quasi-custom software) and the Git and Issue-tracking integration will make a huge difference in your internal processes.

I'd suggest taking a quick tutorial of the software (you can freely download it), and see how far you can get with setting a basic application from scratch. That should help you see the differences and how the concepts maps. There are a lot of similar ideas, but like Git and SVN, there are differences that don't translate very well.

-- Dean

Hi @thomas_3037 and @felfert ,

We heard from another users that creating a new signing key in the feed worked, so please try that.

We didn't experience that in our testing, but I suppose it's not all that unexpected given the scope of the changes. We will update the documentation / blog post and also try to put some guidance in the software via PG-3157 to help other users who encounter an error like this.

-- Dean

Hi @rick-kramer_9238 ,

It looks like you're using ProGet 2023? That functionality was relatively new in that version and there is very possibly some kind of bug linking the two together.

We've since made some big improvements to SCA/compliance, so I would recommend upgrading. Many of the changes were in ProGet 2024:
https://docs.inedo.com/docs/proget-upgrade-2024#new-features-in-proget-2024

-- Dean

Hi @felfert ,

There were major changes to Debian feeds in ProGet 2025.14:
https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds

They were thoroughly tested and we did not encounter issues when upgrading and switching back/forth between versions. As you might imagine, we don't have enough information to help you troubleshoot this - so we'd appreciate if you could investigate further.

It is most certainly a client-related configuration issue and you may need to reconfigure the keys, clear a cache, or something to that effect. Signing keys are typically not changed for already-configured repositories, so this isn't common client behavior.

Please let us know what you find, so we can document appropriately.

-- Dean

Hi @d-kimmich_0782 ,

This behavior is by design; the "publish date" in ProGet 2025 and earlier is whenever a package is added to a feed. This means that, even if a package was published to NuGet.org 3 years ago, the "publish date" will be whenever it was first cached.

However, in ProGet 2025.14 and later, you can change this behavior under "Admin > Advanced Settings > Use Connector Publish Date". This will be the default behavior in ProGet 2026.

This is being done for a similar set of rules you should investigate, which we call Recently Published & Aged Rules :
https://docs.inedo.com/docs/proget/sca/policies#recently-published-aged-rules-proget-2026-preview

-- Dean

Hi @gisleso,

But I'm starting this topic to ask if its expected behavior that formatting of uncached remote packages is a litte off? See screenshots.

Good catch. In this case, the ProGet implementation of the warehouse API (which connectors use) was using the "description" field instead of the "summary" field. Easy fix, it'll be handled via PG-3151 in the next maintenance release

And if anyone have experience with promoting packages including their dependencies I am open to suggestions. (Right now I'm thinking a script that first pull the packages, and the loop to pull/promote the depedencies)

This is frequently requested, but it's simply impossible to do. The only way to solve this is to restore from your unapproved feed, then promote the dependencies into your approved feed.

The reason is that this would require ProGet (or your script) to perform a "dependency resolution" which is impossible to do without environmental context (i.e. other packages installed, operating system, and client configuration).

This is because dependencies are not only specified as ranges (e.g. hypothesis requires sortedcontainers<3.0.0,>=2.1.0) but they often include usage constraints (e.g. hypothesis specifies redis>=3.0.0; when extra=="redis" is specified) and environmental constraints (e.g. hypothesis specifies tzdata>=2025.2 but only when (sys_platform == "win32" or sys_platform == "emscripten") and extra == "zoneinfo").

Only a package manager tool (e.g. pip) can perform dependency resolution, and even then it's not deterministic. This is why lock files are so important too.

-- Dean

Hi @mayorovp_3701,

Based on the message, it appears to be a bug/problem with the GitLab API. It's indicating that the required PackageBaseAddress endpoint is not present in the service index.

Can you share the "service index" (i.e. the index.json) file? It should be present at the root of the API and look something like this: https://api.nuget.org/v3/index.json

-- Dean

Hi @koksime-yap_5909 ,

Data deduplication is an operating-level system function. On Windows, there's the Data Deduplication Feature. There are more options for Linux, but ZFS Deduplication is pretty popular.

-- Dean

Hi @davi-morris_9177 ,

For multi-file packages like PyPI, the entire package (i.e. all the files) is promoted. This is the same in the UI as well.

-- Dean

Hi @Nils-Nilsson,

Thanks for the report; this was a trivial fix and I just committed the change to PG-3138 , which will be in the next maintenance release (Oct 24).

As an FYI, if you uncheck "Restrict viewing download statistics to Feed Administrators" on the Feed Permissions page, then error shouldn't occur.

-- Dean

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

I'm afraid I can't reproduce this data that lead to this error; I did manually hack the database to get it close to what your results showed (i.e. WinSCP and winscp) -- and I got an error the first re-index, but then it got fixed a second time.

At this point, it would require having your database and attaching a debugger to see what's going on. That's a bit more effort than we're able to spend today on a community / non-paid user today, especially given the trickyness of this bug.

HOWEVER -- since you're familiar with PostgreSQL, it might just be quicker to DELETE the duplicate / unused PackageVersionIds and PackageNameIds. That's what we had done in previous versions (2024 and earlier) when there was a problem. Once you have a single record, you can update the casing pretty easily.

Or if you don't care about any packages, just start a new instance of PRoGet and add the packages in. This is all happening b/c "bad data" got snuck in the database in the first place.

-- Dean

Hi @fabrice-mejean ,

Oh I see; that's basically just an alternative URL to query, instead of (or in addition to) official public repositories.

For example, the OSS Metadata Provider for npm is https://registry.npmjs.org. A Custom Provider is one with an alternative URL. Maybe a vendor site, or a differente repository that uses the same APIs?

As the docs mentioned, we have no idea why anyone would want to do that. But it's technically possible.

Thanks,
Steve

Hi @mmaharjan_0067 ,

It sounds like you're on the right track with researching this; your reverse proxy is definitely "breaking things" somehow.

Based on what you wrote, it sounds like your reverse proxy is terminating the request because there's no output from the server after a while. The "no output" is expected, since assembling the upload takes quite some time, and that's likely where the "operation cancelled" would be coming from.

I would look there and see if you can adjust timeouts. As for pgutil, here's the code used to perform the multi-part upload:
https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/AssetDirectories/AssetDirectoryClient.cs#L197

-- Dean

Hi @ashleycanham ,

This is a fairly complicated issue behind the scene, and is related to how these packages have multiple casings across different versions.

This is something that should be addressed with PG-3100. After upgrading, you'll want to re-index the feed. If any packages still have incorrect casing, you can re-upload them to ProGet to correct the names.

-- Dean

Hi @power_pille ,

That's strange; I'm wondering if there's some kind of collation problem on your database.

Can you run this?

SELECT CONVERT (varchar, SERVERPROPERTY('collation')) AS 'Server', collation_name  as 'Database' FROM sys.databases WHERE name = 'ProGet';

What are the collation you're seeing?

ProGet must be SQL_Latin1_General_CP1_CI_AS

-- Dean

Hi @dev_7037 ,

This is not possible and we have no plans to add support for this.

Some users have reportedly used reverse proxies and page/URL-rewriting, but it's a headache and usually causes problems. Best to use a different host name and change URLs accessed by clients.

-- Dean

Hi @Anthony ,

The API Access Logs are intended for troubleshooting purposes, not auditing/access monitoring. So I'm afraid there's no way to increase it.

-- Dean

Hi @power_pille ,

I haven't seen that error before, but I suspect it could occur during a race condition while simultaneously trying to access newly-accessed packages. During an intense package restore, the window for the race condition would widen.

It should go away however. If you can look at the error messages logged in ProGet, it'll help give an idea:

Violation of UNIQUE KEY constraint 'UQ__PackageNameIds'. Cannot insert duplicate key in object 'dbo.PackageNameIds'. The duplicate key value is (nuget, <NULL>, NuGet.CommandLine).

In this case, the package is NuGet.CommandLine -- so hopefully you wouldn't see that again. Let us know if that's not the case, and if you repeadly see the same package.

-- Dean

Hi @yaakov-smith_7984 ,

We do not have this API, but it's on our roadmap for Q4; it's going to be a set of command like pgutil users or something to that effect.

-- Dean

@tames_0545 thanks for letting us know, we'll get this fixed right away via PG-3065 in the next maintenance release

Hi @mickey-durden_1899 ,

I've not heard of OCI's Object Storage before, but that error message is coming from the AWS SDK. I searched it, and it's basically saying that OCI doesn't support payload signing, which is used by chunked uploads?

I'll be honest, I have no idea what that means... but it looks like Cloudflare's version of S3 also doesn't support it. But we can apparently just make a small change to get it working: https://github.com/cloudflare/cloudflare-docs/issues/4683

I'm thinking we could try adding a checkbox to disable Payload Signing:
https://github.com/Inedo/inedox-aws/blob/master/AWS/InedoExtension/FileSystems/S3FileSystem.cs

Assuming we did that, could you install the pre-release extension and try it out? If it works, we'll publish it.

Thanks,
Steve

Hi @misael-esperanzate_5668 ,

Although ProGet can handle invalid version numbers for Maven packages, this one is a extra invalid version number (it starts with a "v") and unfortunately we can't support them at this time.

ProGet requires that packages follow the ~20 year Maven standard that "packages start with a letter and versions start with a number". Sadly this team didn't like those standards and opted to do their own thing.

The issue comes with identifying whether com/google/apis/google-api-services-healthcare/v1-rev20240731-2.0.0 is an artifact or a version. Because ProGet is not a basic file server, things like package names and versions matter.

Anyway this will require a significant and risky change to the API so we won't consider it at least for another major release.

-- Dean

@tames_0545 thanks for letting us know! We'll see if we can improve troubleshooting on this in the future as well!

Hi @darren-sloper_5044 ,

ProGet does not currently produce HTTP Access Logs, though we are considering that for a future release. It's really easy to add it via an IIS reverse proxy (WIndows) or with some NGNIX settings if you're on Linux

Dean.

Hi @Jonathan-Engstrom ,

There's no way to "merge" accounts that I can see, so I just changed the ownership of the handful of posts by @JonathanEngstrom to @JonathanEngstrom and updated emails. Hopefully that works

-- Dean

Hi @kc_2466 ,

We'll get this fixed via PG-3050 as well; the button should be shown to non-admins

-- Dean

Hi @kc_2466 ,

Those should not be displayed to non-feed admins; we'll clear that up with PG-3050 in the next maintenance release. In the meantime, I suppose you could just click the "X" for them ;)

-- Dean

Hi @mmaharjan_0067 ,

We'll investigate and see about adding this via PG-3035; it's probably returning some unexpected status. Will update if we run into trouble!

-- Dean

@mmaharjan_0067 we'll try to do this via PG-3034 as well

Hi @v-makkenze_6348 ,

We'll get this fixed via PG-3041 in the upcoming maintenance release; you can try out the prerelease container if you'd like (proget:25.0.4-ci.1), which is building now.

-- Dean

Hi @c4buildmasters_2588

Short answer yes, and you'd probably see a bit better than 15 -> 5 TB reductions with those artifacts. We usually see 90-95% storage space reduction. Pair it with ProGet's retention rules and I wouldn't be surprised to see that drop to 500GB.

Long answer, file deduplication is something you want handled by the operating system (e.g. Windows Data Deduplication, RHEL VDO, etc), not the application. It's way too complex -- you have to routinely index a fileset, centralize chunks in a compressed store, and then rebuild those files with reparse points.

Maybe this wasn't the case a couple decades ago. But these days, rolling your own file deduplication would be like implementing your own hacky encryption or compression. Pointless and a bad idea.

That being said, you may be using a tool by our friends at JFrog. They advertise a feature called "data deduplication", which IMHO is something between deceptive and a clever marketing flex.

Because they store files by their hash instead of file names, the files are automatically "deduplicated"... so long as it's the exact same contents. Which, in most case, it will not be.

Here’s an article that digs into how things are stored in Artifactory, and also should give you an idea of their “file-based” approach: https://blog.inedo.com/proget-migration/how-files-and-packages-work-in-proget-for-artifactory-users/

As for the package count, 5M is obviously a lot of packages. Obviously it's not going to be as fast as 5 packages - but probably not that much noticeably slower. There's lots of database indexes, etc.

Hope that helps.

-- Dean

@michal-roszak_0767 just a heads up we're a bit slammed with ProGet 2025 release but will respond soon!

@lukas-christel_6718 just a heads up we're a bit slammed with ProGet 2025 release but will respond soon!

@layfield_8963 no plans, as you're the first to ask :)

I don't know much about ARM/MacOS builds.... do you think it's just as easy as adding a new publish target?

See our build script here:
https://buildmaster.inedo.com/applications/132/scripts/all?global=False

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