Hi @dan-brown_0128,

I've tried to reproduce this both inside of Docker and on a clean bookworm vm, and haven't had any luck. It works for me whether the package has been pulled to ProGet or not, no matter how many times I try. Unfortunately I don't have any ideas what might be happening here.

-Greg

Hi @dan-brown_0128,

That is odd! We'll see if we can reproduce it and let you know what we find.

-Greg

Hi @dan-brown_0128,

I would try increasing the timeout period in the connector settings to see if that helps. Are you running ProGet on Windows or Docker/Linux?

Hi @daniel-scati,

Thanks for reporting these. We've fixed the documentation issues, and will have the integration instructions corrected in the next release (v2023.30 as PG-2585).

Regarding the apt-key deprecation, we were aware of that when redoing Debian for v2023.22, but at the time it didn't look like there was any kind of consensus for how to handle trusting a third-party repository, and nearly all other repos we looked at still only gave instructions for using apt-key. We're happy to reevaluate this if there is a better solution available.

-Greg

Hi @caterina,

Microsoft is confusing on this subject - they refer to the old format as legacy sometimes (https://learn.microsoft.com/en-us/nuget/create-packages/symbol-packages) but other times they just imply it's not preferred. Our documentation and the software itself is usually based on the language they used at the time we drafted the feature. I suspect we are just leaning more into the "legacy/deprecated" terminology than they are right now.

In any case, we have no plans to remove support for the symbol package format or anything. Is the problem that we are missing the "Download with Symbols" link now? I can file that as a bug if that's the case.

Hope this helps!
-Greg

Have you had any success deleting these after retagging? We haven't been able to reproduce this so far.

Hi @gunmaden,

Thanks for reporting this! I've filed it for investigation as PG-2519.

Hi @gunmaden,

Right now there is no way to delete a Maven package using an API, but I can put that in as a feature request.

Regarding Python, you have to know the package file name to delete it, and pass it in as part of the qualifer, for example: qualifier=filename%3Dmypackage.1.0.0.tgz

For Debian, the url query string should look like this:

name={name}&version={version}&group={component}&qualifier=arch%3Damd64

Does this help?

-Greg

Sure. I've logged that change as PG-2508. It should be easy enough to make that URL configurable in ProGet.

Hi @itops_6398,

Thank you for the bug report. I've logged this as PG-2507, and we will likely have it fixed for the next release of ProGet 2023.20, scheduled for October 13. If the fix or testing turns out to be more than expected, it may get deferred to the following release, but I don't expect that to be the case here.

Hi @philippe-camelio_3885,

We've reproduced this, and it is a regression in v2023. We will have it fixed in this Friday's release of BuildMaster v2023.2. It is logged as BM-3893.

Thanks!

Hi @zarniak-j_0637 and @philippe-camelio_3885

We should finally have this issue resolved in the latest Inedo Hub (v1.3.19). If it still doesn't work in that version, post another reply here and we'll look into it again.

Thanks!
-Greg

Thanks! Merged and released.

Hi @e-rotteveel_1850

Thanks for the bug report! We will have this fixed in v2023.14 to be released on Friday. It's logged as PG-2446, and looks like a regression from some of the internal consolidation we did for ProGet 2023.

-Greg

Hi @e-rotteveel_1850

Thanks again for the packages and detailed repro steps. I was able to reproduce this and we'll have a fix (PG-2445) in this Friday's release (v2023.14). It appears to have been a regression introduced when we added support for parsing package constrains information from connectors.

-Greg

Hi,

This is a regression in v23 that we have logged as PG-2389. It will be fixed in v2023.8, which is scheduled for release on Friday (June 16).

Thanks!

Hi @MF-60085,

Thanks for the data! We've found that the root cause this time is due to some duplicate rows in the original table, which for some reason was not created with any uniqueness constraints. We'll get this fixed in a prerelease version within a day or two.

We have a prerelease version available with this fix (PG-2354) if you would like to try it. To install on Windows using Inedo Hub, click the [config] link in the bottom and paste in https://proget.inedo.com/upack/PrereleaseProducts/ - you should then be able to upgrade to v23.0.5-rc.4. If you're running in Docker on Linux, just use tag 23.0.5-ci.4.

Hi @jeff-peirson_4344,

Thanks for the detailed steps. I've been able to reproduce this and we should have a fix for it shortly.

As you've seen, we've had a few regression in npm feeds for this release. Historically, npm was the first non-NuGet feed we added to ProGet, and we decided the major version release was a good opportunity to do some badly needed refactoring. Unfortunately, regressions are a result, but we are now able to iterate much more quickly.

Would you be willing to try a prerelease version?

Hi @sebastian ,

Regarding [1], I can't reproduce this behavior. When I add OSS Index I see vulnerabilities from it and also from PGVC, though this is only on the latest v2023 build, so maybe this works differently on another version?

For [2], you are correct. There are a lot more of these in the dataset than we initially thought. We plan to resolve this by filling in the missing data from NVD, though I can't give an estimate on when we will have that (maybe @apxltd can give you a rough idea of our schedule).

Finally, for [3], I think we will end up storing a CVE for most of these to help populate missing CVSS scores if for no other reason. I think this would be part of updates we do to address [2].

-Greg