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

@itops_6398 glad that worked! I noticed same quirk in the UI and fixed it :) Probably why we/no one noticed before... editing the connector just happened to fix it once the value was saved.

Yes, reindexing the directory adds (and optionally removes) files wich were/were not present when the asset feed was setup. We have an existing directory of files which are downloadable by another service. We would like to make (and have made) that directory available as an asset feed in Proget. It's easy enough to point Proget to the existing directory for the feed, and have it index it. This creates the metadata within your system, making the files available to those users who are valid to download them. If I were to add files via a drop directory, it would work, but it would not necessarily add them in the structured manner we have setup in the base directory. Although TBH I haven't tried dumping a directory tree into a drop directory to see what happens. I'll try that. Thanks.

Thanks for the additional feedback; this is definitely something we're revisiting for ProGet 2024. As you described, a lot of the pieces are there - they just aren't wired together very well in some cases. We're working on redesigning this to be more cohesive. A lot of the existing behavior has to do with performance. For example, /packages/from-purl?pUrl=... is a bit of a "hack" that we used. It's the navigation URL, then then redirects you to the proper URL. This is because finding the URL of a package can be expensive, especially when there are 1000's of packages in a SBOM and multiple candidate feeds for each package. Doing big joins across multiple feeds on the FeedPackages is something we need to very carefully do. On the same performance note, "Pulling from the source" can be expensive -- especially when you aggregate multiple feeds into one using connectors. So we need to be really careful before doing that. But like I said, this is something we are redesigning in ProGet 2024; you can think of ProGet SCA features as a "2.0" right now (I guess "1.0" was the old package consumers feature?), and hopefully "3.0" will be a lot closer to getting it right. Cheers, Alana

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

Yep, you are awesome. I know this is an old post, but it was my issue as well. Using a nginx proxy for the server. Thank you.

Hi @Jon, Looks like this was a result of recent change. I have fixed this in OT-499 and will be released in Otter 2022.15. If this is an immediate requirement, I can create a prerelease version of Otter you can install. Please let me know if you are interested. Thanks, Rich

Hi @schuettecarsten_9427 , There's no limitation about that in ProGet... the * is something the NuGet client resolves. Based on the error, it looks like there's a problem with Visual Studio communicating to ProGet. No further information is provided; maybe this is related to ProGet having an issue communicating to Nuget.org through your connector. You'd need to dig into that a bit further. I'd also make sure to use the V3 API Endpoint. The query that's shown in the error is the v2/ODATA endpoint. Cheers, Alana