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?

Hi @artur-wisniowski_4029,

We'll get this fixed, but it's unlikely to be in this week's release. ProGet hashs the complete package file for every package uploaded to it, while the APK spec says to hash only over a certain tar segment of the package. We've been returning ProGet's hash of the package file as the checksum and this is incorrect as you've noted.

We'll post here again when we have a fix date, but I'd expect it will be either next week or the week after.

Thanks!

Hi @pbinnell_2355,

Looks like the example code was incorrect. I've updated it. When a dotnet tool is installed globally, you run it by just running the tool name directly, so pgutil instead of dotnet pgutil

Hope this help!
-Greg

Great to hear! Thanks for the followup

Hi @dan-brown_0128,

I've done some more research on this, and per the spec we definitely should not be url encoding anything in the Filename field: https://wiki.debian.org/DebianRepository/Format#Filename

I've filed this as PG-2591. It's an easy change, so we'll include it in this week's release on Friday. It still is strange that I couldn't reproduce this, but hopefully this will resolve the issue for you and anyone else that is seeing this.

Good find!

I did my testing against unixodbc-common_2.3.11-2+deb12u1_all.deb, and oddly everything worked- I wonder if this behavior varies in different versions of apt?

Anyway, we should change ProGet to match the Debian index behavior, so I will file this as a bug.

Hi @dan-brown_0128 , @stevedennis

I had that thought too, and I made sure caching was enabled when I tried to reproduce this. I have some more ideas for trying to recreate this today - hopefully with more luck this time.

Hi @mlorenzschleipen_5169,

Just wanted to let you know that May 1 was a typo - the release date is actually March 1, so a lot sooner :)

-Greg