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

what if we try it on a sub website i mean a subdomain? it will work or not?

Hi @A-Schoder_7166 , It sounds like your installation is somehow corrupt?? I can't imagine what would cause that error but it's basically saying that the upack.json file within the extension file (xxx.upack) is corrupt. Maybe some antivirus tool went and "quarantined" zip files on disk that contained executable code? Really hard to guess. The file sare loaded , typically in c:\Program Files\ProGet\Extensions, and they are part of the installation. I would uninstall and reinstall, and hopefully that will fix the issue. Thanks, Alana

Thank you for your help! I am hoping that this is enough to lock down nuget restores: API Keys for Pulling/Listing Packages Most clients will not send the API key for operations like listing or pulling packages. In this case, ProGet will issue an authentication challenge, and the client will respond by prompting for a username and password. In this case, you can supply api for the username, and your API key for the password. I'll test that.

Hi @devopsdude3113, What scopes do you have configured for your personal access token? When I tested this, I created a personal access token and added only the read:packages scope. Also, do you see any error in your ProGet diagnostic center? Thanks, Rich

Hi @rhessinger Pb solved, Thanks for your fast correction

Hi @jw , Thanks for reporting these! We'll get the fixed in hopefully the next upcoming maintenance release via PG-2520 and PG-2521 Cheers, Alana

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

Hi @lucas-almeida_8120 , This error implies that there's some kind of database corruption or other error that happened while updating the database a while ago. But it's hard to say; this is the first time I've seen this error. Unfortunately, unless I were to analyze a backup of your database and try to reproduce the installation/upgrade, I won't be able to offer any guidance or scripts that could repair the state of things. From here, I would recommend rolling back to whatever version was working, then starting a new ProGet server and importing your packages. Best, Alana

Hi @jimbobmcgee, I just wanted to let you know that we just released Otter 2023 and it includes the name filter on the List action type on the Infrastructure API. Thanks, Rich

Thank you for the pointers. I think I finally got it working, though I must admit I'm still not a 100% sure what combination in what order actually led to success. I'm already in contact with @apxltd about your planned SCA changes. I will try to write up what tripped me as part of that feedback.

Hi @haralambop_0645 , A 403 error means that the user does not have the required permission to perform the action. So you'll need to make sure that feeduser is authorized to push packages to the feed, which you can do under Admin > Tasks. Cheers, Alana

Thanks @carl-westman_8110 , I appreciate the feedback!! As someone coming from Azure Artifacts, I'd love to get your impression on our draft ProGet vs Azure Artifacts page - we're slowly starting to try to articulate the high-level differences and benefits to ProGet. But I swear marketing copy about the software is harder to write than the software itself We also have BuildMaster vs. Azure DevOps comparison page too, though it's quite a bit more involved.

You may have also seen this message but... What Windows server version is Otter installed on? That might help us narrow this down. We have seen that error if RSAT is not enabled: https://learn.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/remote-server-administration-tools Cheers, Alana

Thanks for the update @mness_8576; based on this, it sounds like there's definitely a Gateway problem, and that the Gateway is misconfigured / misreporting some error condition from ProGet due to a quirky package request. That's a pretty common thing we've seen as well.

Hi @itops_6398 , On a remote package (i.e. the ones with the radio icon), the download count is whatever is presented by the remote feed. On python packages, some have negative numbers. Once you pull or cache (i.e. download) the package , the count will start at 0 and ProGet will keep track of the download count. Cheers, Alana

Hi @itops_6398, I'm very happy to hear that you got this working. You typically do not need the UPN because it will be automatically appended when searching for the user in your domain, but it doesn't hurt to be there. There are typically only two scenarios when the UPN is needed; when that username is already in the built-in directory or you have a multi-domain forest setup in Active Directory, then the UPN will tell it specifically where to look. With all that said, if it is working for you now, then I would leave it as is because SAML and AD/LDAP are difficult enough as it is. We are going to add the transform information to our SAML docs in hopes of helping others later. Thanks, Dan

Hi Dan! My IT department solved the issue for now by ignoring certificate errors for LDAPS as per your suggestion above while it would be nice to get it to work "correctly" i'll wait until there is a guide available on how to set it up to not have to ignore the errors Many thanks for all your help! For future reference and people [image: 1697113463152-8858e4fd-80d1-491f-8c65-c559c7276ddd-image.png] [image: 1697113553496-f2ffb7da-c5f6-40b7-b246-a5efe8fcaaec-image.png]

Hello @atripp I'm confused. I had several nuggets that could not be pushed via the command and I did not verify the renaming to .zip on all of them. When I tried the "Drop Path" method I tried on one that I hadn't checked. With your message that it's been 10 years since you've had a problem like this. I started again from scratch and I noticed that this Nuget indeed does not open with windows but it opens with 7zip. What's more, I asked our teams and this nuget is not necessarily good. What put me in error was that it was in our old binary manager and that our new binary manager accepts it. I'll be able to do some more tests on replication. Thank you for your help