Posts made by gdivis

Hi @brandon_owensby_2976,

Yes, that actually does wire things up with OtterScript, though I just realized I forgot to include a sample for how to actually invoke that script from OtterScript...

PSCall2 MyScript.ps1
(
    Parameters: %(inputvalue: Hello, resultingtext: outputvar)
);

Log-Information MyScript returned $outputvar;

The Parameters argument is meant to handle anything declared as an input/output value in the script's header. Note that for outputs you actually supply the name of the OtterScript variable to assign as the parameter value. For the record, I agree that this is all very confusing and we could certainly do a better job in the UI and docs. I believe the original goal when we added PSCall2 was to make the script parameters more discoverable, but at least as it works now, it has had the opposite effect.

That crazy stuff with the prefix is the mechanism it uses behind the scenes to capture output values that are declared in that parameters header or in the OuputVariables argument.

Does using this kind of header and PSCall2 invocation work at all for you? There's other things that could go wrong with marshalling values to/from PowerShell, but this ought to at least get you outputs without having to jump through those extra hoops.

-Greg

Hi @brandon_owensby_2976,

You're right that this is not very intuitive, and there are some outstanding issues we intend to fix in BuildMaster 2026. Generally, the best way to get all of this wired up right now is to have an Augmented Help header in the PowerShell script like this:

<#
.SYNOPSIS
    Appends world.

.AHPARAMETER inputvalue
    Input string

.AHPARAMETER resultingtext(output)
    Will be set to the resulting text

#>

param ([string]$inputvalue, [ref]$resultingtext)

$resultingtext = $inputvalue + " world" 

The key here is the [ref] specifier in the param block and the (output) specifier in the .AHPARAMETER augmented help header above.

For scripts without a param/Augmented Help header, you should be able to use the InputVariables and OutputVariables parameters of PSCall2 instead.

This is unfortunately missing from the docs at the moment, but before getting that updated I'd like to see if we can streamline or improve this to make it more intuitive.

Does this help at all? We're happy to work with you to improve this before the 2026 release.

Thanks!
Greg

Hi @Nils-Nilsson,

We've released pgutil 2.4.0 that has the audit command, along with a couple new commands under containers for adding/deleting tags. Note that it requires APIs added in ProGet 2026.3 or later.

Give it a try and let us know what you think.
-Greg

Hi @appplat_4310,

It shouldn't be a problem to get this in today's release (2026.2). I've logged it as PG-3295.

-Greg

Hi @Ashley,

It turns out that we just weren't reading upload-time from the upstream json when using the simple API, so this was pretty trivial to fix and we'll certainly be able to include it in tomorrow's release. Here's the abbreviated result of a quick local test I did after making the fix (also after fixing the issue with the duplicated versions):

{
  "meta": {
    "api-version": "1.1"
  },
  "name": "psycopg",
  "versions": [
    "3.0b1",
    "3.0",
    "3.0.1",
    "3.0.2",
    "3.0.3",
    "3.0.4",
    "3.0.5",
    "3.0.6",
    "3.0.7",
    "3.0.8",
    "3.0.9",
    "3.0.10",
    "3.0.11",
    "3.0.12",
    "3.0.13",
    "3.0.14",
    "3.0.15",
    "3.0.16",
    "3.0.17",
    "3.0.18",
    "3.1",
    "3.1.1",
    "3.1.2",
    "3.1.3",
    "3.1.4",
    "3.1.5",
    "3.1.6",
    "3.1.7",
    "3.1.8",
    "3.1.9",
    "3.1.10",
    "3.1.11",
    "3.1.12",
    "3.1.13",
    "3.1.14",
    "3.1.15",
    "3.1.16",
    "3.1.17",
    "3.1.18",
    "3.1.19",
    "3.1.20",
    "3.2.0",
    "3.2.1",
    "3.2.2",
    "3.2.3",
    "3.2.4",
    "3.2.5",
    "3.2.6",
    "3.2.7",
    "3.2.8",
    "3.2.9",
    "3.2.10",
    "3.2.11",
    "3.2.12",
    "3.2.13",
    "3.3.0",
    "3.3.1",
    "3.3.2",
    "3.3.3",
    "3.3.4"
  ],
  "files": [
    {
      "filename": "psycopg-3.0b1-py3-none-any.whl",
      "url": "http://localhost:5000/pypi/snake/download/psycopg/3.0b1/psycopg-3.0b1-py3-none-any.whl",
      "requires-python": ">=3.6",
      "size": 131830,
      "upload-time": "2021-09-03T21:34:46.638478Z",
      "hashes": {
        "sha256": "fd510caaaa90aec11781c0581a8a03f847e35925db6de293404db87d625a44e8"
      }
    },
    {
      "filename": "psycopg-3.0b1.tar.gz",
      "url": "http://localhost:5000/pypi/snake/download/psycopg/3.0b1/psycopg-3.0b1.tar.gz",
      "requires-python": ">=3.6",
      "size": 108312,
      "upload-time": "2021-08-30T04:25:06.027667Z",
      "hashes": {
        "sha256": "90188a415f2132eabccfa58ae41330d3bfc1c5c410add4d6194e783521478189"
      }
    },
    {
      "filename": "psycopg-3.0-py3-none-any.whl",
      "url": "http://localhost:5000/pypi/snake/download/psycopg/3.0/psycopg-3.0-py3-none-any.whl",
      "requires-python": ">=3.6",
      "size": 140812,
      "upload-time": "2021-10-12T16:20:12.084578Z",
      "hashes": {
        "sha256": "65b9fb8838dae61040ad3e0cfc184d4ffd17f740ef4c0353d76050a6eb061a9c"
      }
    }
    //...SNIP
  ]
}

Offline installers are available here which you can use to upgrade these older versions:
https://my.inedo.com/downloads/installers

We've tracked this down to an issue with native symbol files indexed in a PostgreSQL database. It will be fixed by PG-3243 in ProGet 2025.24, scheduled for release tomorrow (20 March 2026).

Packages with affected symbol files should be re-uploaded to ProGet following this release to resolve the lookup issue.

You can test the fix from this prerelease image: proget.inedo.com/productimages/inedo/proget:25.0.22-ci.4

In this version, it will automatically recreate each of those databases the next time it needs an update, and after that you should no longer see this unbounded growth. Let us know if you're still seeing a problem!

Hi @geraldizo_0690,

We've reproduced this and have a fix in internal testing as PG-3225. An incorrect index is causing the local connector database index to grow much larger than it should, and this effect is compounded in frequently updated repos like Kali.

We are currently testing the fix internally and will have it included in Friday's release of ProGet 2025.22. If you'd like to test the fix yourself soon, I can make a prerelease image available to you.

Thanks!
-Greg

Hi @Sigve-opedal_6476,

I haven't been able to reproduce this in a Rocky 9 test environment. After setting up the feed and connector in ProGet I ran dnf install zabbix-sql-scripts, and then repeated the test a few times with different versions and variations on formatting the versions. I also tried with cached and uncached packages. I was able to get a 404 to happen one time, but it was due to the upstream repo returning a 404 at the correct URL - which then worked the next time it was tried.

Is this happening consistently for you?

Hi @udi-moshe_0021,

It actually is already bundled with the installer and should have been run before ProGet's installation. I'm not sure why it would have failed, but we'll add more checking to at least provide a warning if this fails in the future.

Thanks for letting us know what the problem was!

Thanks! This will be fixed in today's release of ProGet 2025.17 as PG-3187.

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:

1. The extension should target net8.0, not net9.0
2. You need an = after build, so the command should be dotnet inedoxpack pack --build=Release

If 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:

• upload/delete a package
• wait 30s
• get repodata/repomd.xml

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.

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!