Just to keep everyone informed: We are pretty sure we have the underlying issue resolved as of PG-3158. We were incorrectly supplying the wrong InverseQ value to OpenSSL when reading a key from an existing file - so this impacted both uploaded keys and keys from previous ProGet versions. This will be included in next Friday's 2025.15 release, but is available right now at proget.inedo.com/productimages/inedo/proget:25.0.15-ci.4 if anyone would like to test it immediately.
We've now reproduced this and resolved it as PG-3156. It will be included in next Friday's release of ProGet 2025.15. It's also available now in inedo/proget:25.0.15-ci.1 if you'd like to try it sooner. Note that due to the way the repo indexes are generated in ProGet, it may be necessary to rebuild the connector index on the manage connector page in the new version.
Thanks for reporting the problem! If you're curious it was due to a peculiar format Rocky Linux's repositories used - technically correct but different from all of the other ones we've tested.
Hi @yakobseval_2238,
I see two problems:
net8.0, not net9.0dotnet inedoxpack pack --build=ReleaseIf you correct both of those it should work, but let us know if you still have problems after that.
This would be a relatively easys change to make, but we'd like to be able to test it against a public repository that has noarch packages included in its index. The https://dl-cdn.alpinelinux.org/alpine/v3.21/main/x86_64/APKINDEX.tar.gz index file doesn't seem to have anything except x86_64 packages in it. Is there a good public repo we can use as a solid source of working example data?
Thanks for pointing this out! We missed this detail of the APKINDEX specification and will get this fixed as PG-3132, likely in this week's release of v2025.12 on Friday, but potentially in a later maintenance release if it is more complex than expected.
Thanks for the further info - I'll make sure we retest with Server 2025.
Hi @reseau_6272 and @aristo_4359,
Thanks for reporting this. The installer does add write permission to those directories but not read, I suppose under the (invalid?) assumption that all users by default have read access to there already. I've created PG-3112 to track this - we will likely have it fixed in this week's release (2025.10) or possibly 205.11 in two weeks.
-Greg
Any change to feed that could affect a package is supposed to trigger this, and that does include deleting a package, adding a package, or a detected change in any repodata files from any associated connectors. What happens is any operation like that sets an index dirty flag for the feed, and if a request is made for it after that, it is rebuilt. There is also a 30 second delay before this can get triggered, so if you:
It should show an updated timestamp and revision.
We are currently moving to more of a job-based system for these index rebuilds, which also will provide better visibility into their creation and allow for manually triggering them. We're starting this process with Debian feeds since those exhibit the most problems with the current system, but plan to extend it to rpm and apk as well.
Anyway, if you're not seeing it update even after the 30s delay then there must be some other issue at work, so we'll need to dig into that.
Hi @felfert,
Apologies for the delay, I was out of the office recently. We tested this one quite a bit before release and didn't see any cases of the index not getting updated. Of course, I believe you that it is happening, but it's not something I've been able to reproduce. One thing to note is that those repodata files in storage only get updated on-demand - so something would have to actually make a request for the index to get ProGet to rebuild it (this is something that we are planning to change in a separate issue, but that is how it works currently).
Of course, we'd be happy to do some testing with your packages specifically if you'd like to upload some - just open a ticket at https://my.inedo.com/tickets/new which does allow file attachments. Ignore the header that says it's for paid users only; we'll associate it with this forum post.
-Greg
We've now fixed this and several other related RPM issues as PG-3094, scheduled for release this Friday in ProGet 2025.9. Thanks again for the bug report!
Hi @carsten_1879,
Thanks for trying it out. It is new, and has not been tested as much against older repositories. That said, we've reproduced this error and it's now fixed in the latest build - buildmaster:25.0.0-ci.28 if you would like to try it again. It's caused by older repos that don't support offset deltas being transmitted during a clone or fetch. Small repos that we used for testing ADOS so far were not large enough to have deltas at all, so those worked. So far as I can tell, the repository name containing a dot doesn't have any effect.
Thanks!
-Greg
Hi Marc,
Thanks for the note! That file is actually a sort of cross-platform way of storing symbolic links. BuildMaster also includes all the binaries needed for agents on both Windows and Linux, including .net runtimes for all three. In order to save space we deduplicate identical binaries from the agents. We use a simple json file instead of proper symlinks because we use the same file on Windows/Linux and it's easier this way. All the paths in the file have historically used Windows path separators due to how we generate it, and we convert those in BuildMaster at runtime to the proper format.... or at least we were supposed to. At some point there was a regression added that caused this to not happen when updating from Linux.
Anyway, this will be fixed as BM-3981 in the next release :)
There was in issue with Docker container initialization due to some of the updated startup code in ProGet 2025 - it's now been resolved, and if you pull the proget:25.0.1 it should work.
Hope this helps!
This looks like it was caused by us packaging an old version of Inedo Hub as part of the offline installer. We'll have it fixed for the 2025.1 release which will go out this week.
Hi @layfield_8963,
We've added osx-arm64 as another target, and we'll start deploying that along with the other binaries. We'll probably push out a new release today or tomorrow.
Thanks!
Hi @layfield_8963,
Looks like this was just a simple bug preventing output from being written when stdout has been redirected. It's now fixed in pgutil 2.1.1.
Thanks for the update!
-Greg
Hi Fritz,
We appreciate the feedback on this! ProGet 2025 will indeed have a separate dedicated mount for the database, but we didn't include this in the preview. As to the other issues, yes we do have a supervisor that attempts to start postgres and perform a clean shutdown on container stop... but there are some bugs we are working through, likely made worse by the ownership issues you discovered.
These concerns will absolutely be addressed before launch.
Again, thanks for trying it out and please let us know of any other issues you find or suggestions you may have!
-Greg
Hi @dimas,
I've looked into this and it appears that restricted and multiverse in noble-backports do not actually have any packages in their indexes. It's a quirk of how these connectors are implemented in ProGet that components with no packages indexed are omitted from the output index. Is this causing a problem for you? We can look into changing this behavior, but it likely won't be a trivial fix.
-Greg
Just to let you know - the PR has been merged and we'll release AWS 3.1.2 on Friday with the fix included. Thank you!
pgutil 2.1.4 is now released which has this capability. Note that in bash you'll need to quote the argument to prevent the shell from doing the globbing.
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
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!
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?
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.
Just wanted to let you know that May 1 was a typo - the release date is actually March 1, so a lot sooner :)
-Greg
Hi @dan-brown_0128,
I've tried to reproduce this both inside of Docker and on a clean bookworm vm, and haven't had any luck. It works for me whether the package has been pulled to ProGet or not, no matter how many times I try. Unfortunately I don't have any ideas what might be happening here.
-Greg
Hi @dan-brown_0128,
That is odd! We'll see if we can reproduce it and let you know what we find.
-Greg
Hi @dan-brown_0128,
I would try increasing the timeout period in the connector settings to see if that helps. Are you running ProGet on Windows or Docker/Linux?