Hi @jblaine_9526,

Good idea, we'll add this!

That's a display issue in pgutil. It's not supposed to show the build number as part of the version at all, so we'll fix that. Note that we do include the build as part of the tag, but the actual release title on GitHub is just 2.1.1, 2.0.6, etc. Thanks for reporting this!

Looks like I had misunderstood the exact problem. One related issue was already fixed in 2024.25, but the aggregation issue with one connector having a package and another not having it was not. I have confirmed that both will be fixed in today's release of 2024.26, along with that Invalid Feed Type error.

Sorry for the confusion!

Hi Scott,

This fix will be included in tomorrow's release (2024.4).

Thanks!

Unfortunately it turns out that this is more complicated than we expected. You are correct about it being normalization-related. When packages are added to ProGet, essential identifying metadata like name and version get indexed in the database, and versions are supposed to be normalized when used this way. However, it looks like this normalization is not occurring for Conda packages.

We don't want to just do the obvious fix and start normalizing them, as that could lead to duplicate packages getting added and issues with replication. So, what we propose to do is extend our feed re-index operation to detect nonnormalized versions and fix, and then start normalizing versions consistently.

Long story short - it's not going in tomorrow's release, but we have a plan to get it fixed.

Hi @kc_2466,

I can't reproduce this in ProGet 2024.25. Is it possible you are using a prerelease version? It should report ProGet 2024.25 Build 11 in the page footer.

I'm confirming because this was fixed across all feeds as a relatively late commit before the release.

Thanks!
-Greg

We've added both of these properties to the index - you should see them in this week's release of 2024.26 on Friday. Thanks for the feature request!

We're still investigating this one, but we'll likely have a fix for it in ProGet 2024.26 this Friday, but if it ends up being more complex than we are expecting, it could be in the following release later this month. Thank you!

Hi, thanks for reporting this! I've reproduced it and we'll have a fix in ProGet 2024.26, which is scheduled for release on Friday.

@kc_2466 Thanks for reporting these issues! They turned out to be trivial to fix, so we are able to include them as PG-2879 and PG-2880 in today's 2024.25 release.

Hi @kc_2466,

Looks like download uses an API we haven't implemented. Didn't expect that it would use a different mechanism from install! I don't think we'll get a fix for this in tomorrow's release, but I'll schedule it for the following on Feb. 7 (should be v2024.26).

Thanks!

Hi @it4it_9320,

That's about the size I'd expect for a connector to that index. So far, I can't get it to grow much beyond that - I'm wondering if this was caused by the transaction rollback after the constraint error happening over and over. In any case, we'll add an explicit VACCUUM after major updates that ought to prevent the index from expanding again.

-Greg

Hi @it4it_9320,

I've confirmed that the constraint violation issue will be fixed in this Friday's release of ProGet 2024.21.

Regarding the other issue about growing indexes, which remote repository are you seeing this with? Is it the same one that exhibited the constraint error? In all of my testing, the sqlite index is usually in the range of 2-10MB - it's nothing more than the contents of the Packages index file.

-Greg

Hi @Scati

Working with package qualifiers and purls is a little confusing with the API because they are already in a URL encoded query string format and you have to encode them again to be passed in through the API url. If you url encode what you are passing in to purl= then it should work:

https://serverip/api/packages/unstable-lin/delete?purl=pkg%3Adeb%2Fscatinat%407.2.2.0-1%3Farch%3Damd64%26component%3Dscati%26distro%3Djammy

The complexity of dealing with these is the reason we added all of the extra arguments and handling in pgutil to build these qualifiers out more easily.

Hope this helps!
-Greg

Hi Caterina,

pgutil does have the capability to do this if you use the builds sbom command. Apparently this command is hidden from the command list for some reason, but if you run pgutil builds sbom --help it should still show the options for it.

Does this help?
-Greg

Thanks @russell_8876! I've gone ahead and released pgutil 1.1.6 with a fix for this. Give it a try and let us know if it's still not working.

-Greg

Hi @caterina,

You are not overlooking anything, but we did :). We're still in the process of finalizing the commandsets for builds and projects - what we have in there now is something of a placeholder. I'll make sure we get that flag in the finalized version. We plan to have them done by early next week at the latest.

Thanks!
-Greg

Hi @Darren-Gipson_6156,

It looks like we hadn't published the latest version of inedoxpack to nuget.org. I've now published it manually, so if you run dotnet tool update inedo.extensionpackager, it should update to v1.0.7, which will be able to build the extension.

Sorry about that!

Hi @daniel-scati,

I've logged (and fixed) the duplicate versions issue as PG-2686, and that will be included in today's release (ProGet 2024.4).

Regarding the delete command, I've gotten it working using this command:

pgutil packages delete --source=scati --feed=stable --package="pacomalarmprocessor" --version=7.2.1.0-1 --qualifier="arch=amd64&component=scati&distro=bionic"

The only change I made was to put in the full version string instead of just 7.2.1.

Agreed on it being confusing that it succeeds even if the package wasn't found. That was one of those things that made sense in specification (why should I care if the package I want to delete doesn't exist?) but in practice it just hides an error. I think we'll eventually change this API to return an indication that something was actually deleted.

Hope this helps!

Hi @philippe-camelio_3885,

I've tried to reproduce this and I think the issue is that your variable is using JSON array notation instead of otterscript. So, it should be:

@(%(Nom:"Carbon",Version:"2.15.1"),...

It seems to work for me when I format it that way. Does this help?