administrators

Hi @jfullmer_7346,

It's nothing you did.

The underlying issue is that a bug in ProGet allowed WinSCP (ID=563) to be added to the PackageNameIds table; that should never have happened since nuget is case insensitive. We've since fixed that bug.

However, once you have a duplicate name, weird things happen since querying for "give me the PackageID for nuget://winscp" returns two results instead of one. So now when you query "give me the VersionID for (ID=563)-v6.5.3", a new entry is created.

This has been a very long-standing issue, but there aren't any major consequences to these "weird things" except casing in the UI and the health check now fails.

But we're on it :)

Thanks,
Alana

Hi @pmsensi ,

Can you take a look at this thread?

https://forums.inedo.com/topic/5493/request-for-creation-of-api-for-package-auditing-before-dependency-restoration/7

I believe that new API proposal ( pgutil packages metadata) would contain that information -- please share your thoughts in that thread so we can keep it in one place.

Thanks,
Steve

Hi @wechselberg-nisboerge_3629 ,

Given how you uploaded the file, the only scenario that I could see this happening is if the file on disk is somehow corrupted. For example, if you were to locate one of the .rpm files on disk and change a few bytes with a hex editor, I would expect this exact error to occur.

A feed reindex could would never fix this and obviously files cannot "heal themselves". However, this is exactly how hardware behaves, so I would look into that.

Thanks,
Steve

Hi @aristo_4359,

Thank you for sending that over. I have recreated the issue and created PG-3116 to track the fix. We should have this resolved within the next two maintenance releases of ProGet.

Thanks,
Rich

Hi @aristo_4359,

Is this all rpm packages or just specific versions of a package? Can you share package names and version on the ones that will not delete?

@aristo_4359 said in RPM Bulk Edit Delete does not work:

Also a suggestion, when user delete package the page ideally stay on same page, instead redirecting to main feed on deleting single package and redirecting to first page when deleting using bulk edit

Thanks for the suggestion. The reason we redirect to the feed page after deleting a single package is because we don't know if the package will still exist (has other versions and/or is a remote package) in that feed. Although it is not trivial to check before we redirect, it could be added. I am going to add this to the list to discuss for ProGet 2026.

Thanks,
Rich

Hi @m-ruf_4197,

Sure thing! I have added ticket PG-3115 to track the feature. It should be released within the next couple of maintenance releases of ProGet.

Thanks,
Rich

Hi @jfullmer_7346 ,

I haven't had a chance to look into more details, but thanks for providing the results of the query.

FYI - the PackageNameIds and PackageVersionIds are designed as a kind of "permanent, read-only record" -- once added they are not deleted or modified. Even if all packages are deleted (i.e. FeedPackageVersions). This is why this the "duplicate name" is such a headache to deal with.

That said, on a quick glance, we can see exactly where the error is coming from: there are duplicate versions (i.e. (ID=563)-v6.5.3 and (ID=562)-v6.5.3). So, when we try to deduplicate (ID=563) and (ID=562) (i.e. winscp and WinSCP), we get the error as expected.

What's not expected is that those versions were not de-duplicated in the earlier pass. My guess is that it's related to winscp being in one feed and WinSCP being in the other -- we tried to be conservative, and keep the de-duplication to packages related to the feed.

I'm thinking we just change that logic to "all packages of the feed type". Anyway, please stay tuned. We'll try to get it in the next maintencne release.

Thanks,
Alana

Hi @wechselberg-nisboerge_3629 ,

This error is the result of a "bad rpm package" (basically one that is compressed using a method we don't support) getting accepted into ProGet. It should have been rejected on load -- if ProGet cannot open a package file due to unsupported compression, then I'm not sure how it would have indexed the package.

You should be able to find which package it is by going to the "packages" tab at the top of the UI; when you click on the rpm package, it will give a similar error.

How did you add this package? What package is it? This is an error we can definitely fix if we can figurer out how you got the unsupported package in there.

Thanks,
Steve

Hi @wechselberg-nisboerge_3629 ,

These specific errors would have no impact on performance, feed loading, nor would they cause ProGet to "break down" in any manner. And rebooting would most definitely not help, since they stem from bad/corrupt data.

One possibility is that you have bad hardware - that causes peculiar and sporadic errors just like these that cannot be reproduced,.

I can only imagine how frustrating this is, but your experience is atypical and without reproduction cases we really don't know how to help. I would focus on trying to reproduce -- if it's indeed "bad data" that you are uploading, it would happen every single time.

Thanks,
Steve

@albert-pender_6390 great news!

And thanks for the heads up, I just updated the docs