Hi @daniel-mccoy_4395 ,

About the only way I can imagine that happening is if you delete the version from the feed and navigate to that page. Or, if it was a remote package, and somehow the connector stopped working between pages.

I would try to find a pattern and see if you can reproduce this more consistently.

Thanks,
Steve

Hi @Nils-Nilsson ,

This will be fixed via PG-3266 in the upcoming maintenance release (next Friday). It looks like it was a separate, SQL Server only bug. It's easy to patch if you'd like the SQL Script. Just let us know!

Cheers,
Steve

Hi @scusson_9923 ,

Looks like this is a bug in not overriding the job/execution status; the force normal statement should make it "green" and a normal execution status. Anyway we'll get it fixed via OT-524.

Cheers,
Steve

Hi @adoran_4131 ,

It looks like the 404 error is occurring while trying to download the Release file (i.e. the index) for the repository. The file is being downloaded from this URL:

{connector-url}/dists/{distro}/Release"

And that URL is returning a 404. So make sure you are entering the correct distro in the connector.

Thanks,
Steve

Hi @matthias-schmitz_2037 ,

The "Signature ... was created after the --not-after date" message is coming from sqv (Sequoia-PGP verifier), which newer versions of APT use for signature verification.

It almost always indicates a system clock problem on the affected machine, not a repository problem, and often means "The system clock is behind the signature creation time."

So bottom line, I would check the clocks to make sure they are accurate.

Thanks,
Steve

Hi @scusson_9923 ,

The message is expected, but you should see scriptExists: false written at the end, and aNormal status (i.e. green) for the execution.

Is that not the case?

Thanks,
Steve

Hi @scusson_9923 ,

Sorry on the slow reply; i wanted to test this, but didn't get a chance and figure I'd just share this now (which should work):

set $scriptExists = true;

try
{
    Get-Asset FooBar.ps1
    (
        Overwrite: true,
        Type: Script,
        To: D:\temp\FooBar.ps1
    );
}
catch
{
    set $scriptExists = false;
    force normal;
}

Log-Information scriptExists: $scriptExists;

Cheers,
Steve

Hi @v-makkenze_6348 ,

This is a regression introduced from ProGet 2025.20's changes to malicious package handling. It's not intentional, and only the specific versions should be blocked (8.10.1, 9.1.1, 10.1.6, 10.1.7)

We'll get it fixed via PG-3227 in the next maintenance release (scheduled for this Friday, but we may do a pre-release sooner). For now your best bet is to rollback to ProGet 2025.19.

Thanks,
Steve

Hi @daniel-pardo_5658 ,

This behavior is expected; the UI is meant for creating basic, case-insenstiive archives.

As for the permissions.... File metadata (including owner, execute permissions, etc) are stored within the filesystem (or as metadata in a zip file)... so once you transmit a file, that information is irrevocably lost.

Best to upload a package file.

Cheers,
Steve

Hi @daniel-pardo_5658 ,

Thanks for the suggestion; Universal Packages already support tags in the package manifest file: https://docs.inedo.com/docs/proget/feeds/universal/universal-packages#manifest

Otherwise, if you're referring to "tagging" a package already added to a feed - that's a hard pass :)

The reason is that a package is designed to be self-contained (i.e. all the metadata about the package is stored within the package) and cryptographically sealed (i.e. so you can't edit/mutate a package). Tags break these, as they apply semantic metadata outside of the package.

These have caused big issues in ecosystems that have tried them (like npm) - but long story short, there's a good reason they don't exist and there's most certainly a better way to accomplish what you're trying to :)

Cheers,
Steve

Hi @geraldizo_0690,

Thanks for the pointers -- now as an FYI, these settings would have to be a Feed-level setting, but the drop-downs would be the same.

FYI, here's the code we use to generate the Release file --- I'm not sure what those other header values do, but we probably wouold just want to add the two you suggested.

What do you think?

I suspect this will be a quick, opt-in change!

private void WriteReleaseFile(Stream output)
{
    using var writer = new StreamWriter(output, InedoLib.UTF8Encoding, leaveOpen: true) { NewLine = "\n" };
    writer.WriteLine($"Suite: {this.Distro}");
    writer.WriteLine($"Codename: {this.Distro}");
    writer.WriteLine(FormattableString.Invariant($"Date: {this.Generated:ddd', 'dd' 'MMM' 'yyyy' 'HH':'mm':'ss' UTC'}"));
// NotAutomatic: yes  <-- add here
// ButAutomaticUpgrades: yes <-- add here
    writer.WriteLine($"Architectures: {string.Join(' ', this.indexes.Select(i => i.Architecture).Distinct(StringComparer.OrdinalIgnoreCase))}");
    writer.WriteLine($"Components: {string.Join(' ', this.indexes.Select(i => i.Component).Distinct(StringComparer.OrdinalIgnoreCase))}");

    var desc = FeedCache.GetFeed(this.feedId)?.Feed_Description;
    if (!string.IsNullOrWhiteSpace(desc))
        writer.WriteLine($"Description: {desc.ReplaceLineEndings(" ")}");

    writeHashes("MD5Sum:", i => i.MD5);
    writeHashes("SHA1:", i => i.SHA1);
    writeHashes("SHA256:", i => i.SHA256);
    writeHashes("SHA512:", i => i.SHA512);

    void writeHashes(string name, Func<IndexHashData, byte[]> getHash)
    {
        writer.WriteLine(name);
        foreach (var i in this.indexes)
        {
            writer.WriteLine($" {Convert.ToHexString(getHash(i.Uncompressed)).ToLowerInvariant()} {i.Uncompressed.Length,16} {i.Component}/binary-{i.Architecture}/Packages")
            writer.WriteLine($" {Convert.ToHexString(getHash(i.GZip)).ToLowerInvariant()} {i.GZip.Length,16} {i.Component}/binary-{i.Architecture}/Packages.gz");
        }
    }
}

Hi @brandon_owensby_2976 ,

It sounds like you're on the right rack with troubleshooting; the issue is definitely on the server-side in this case, so I asked ChatGPT. Who knows if any of this is accurate, but...

This is a very common situation with older versions of Bitbucket Server (especially pre-6.x / pre-7.x era, but even up to some 7.x versions in certain setups).

The REST API (e.g. /rest/api/1.0/...) and the Git Smart HTTP protocol (/scm/.../info/refs, /git-upload-pack, etc.) are handled by different authentication filters in Bitbucket Server.

Most likely you're using a Personal Access Token / HTTP Access Token (most frequent cause in older versions). In many Bitbucket Server versions (especially ≤ 7.17–7.21), HTTP access tokens were designed mainly for REST API and did not work reliably (or at all) for Git over HTTPS in many cases.

As a workaround , you need to use a real username + password (or username + app password if 2FA is on) for Git operations

We've seen similar in really old version of ADO, GitHub, etc, where API tokens wouldn't work for Git.

Anyway, I would try that - at least from the curl side of things. And maybe upgrading will help as well. If it works, then you'll likely only be able to use a Generic Git repository with a real username/password -- and just create a special builds user which effectiveely acts like an APi key.

Cheers,
Steve

Hi @Stephen-Schaff,

It seems pretty easy to add these up and display them on the screen! I suppose the "hard part" is the UI...

A "Total" line doesn't seem to look right. And it seems like too little information to put in one of those info-boxes. "Total Size: XXXX MB" at the bottom just looks incomplete.

Any suggestions? I'm struggling a bit to see how it could be displayed without looking a little out of place... and since it was your idea I figured I'd ask ;)

Thanks,

Steve

Hi @geraldizo_0690,

Hello,

I'm not all that familiar with Debian/APT... but I briefly researched this, and it seems like this involves adding values like this at the top of the Release file like this:

NotAutomatic: yes 
ButAutomaticUpgrades: yes

Is that it really? And this setting would impact the entire feed... but have no real relation/impact to connectors or packages?

If that's the case, how would you envision configuring this? I'm thinking on the Feed Properties page, but perhaps as a checkbox? How do other products/tools do it in your experience?

Thanks,
Steve

Hi @brandon_owensby_2976 ,

Thanks for the feedback. Based on what you described, it sounds like...

• BitBucket Server API is working fine
• Git API is not working due to a failed/failing authentication challenge

You were able to confirm this with the "Generic Git Repository" also not working. If you were to do a curl -I -u USERNAME;APIKEY https:/.../.git you would most certainly get a 401 response as well.

Anyway that's where I would start -- try to figure out why the Git API is not accepting the credentials. It's most likely related to permissions on theh key, but it's really hard to say... just a guess.

Thankks,
Steve

Hi @Julian-huebner_9077 ,

Here's some information on file storage paths:
https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-feed-storage

Long story short, if you modify Storage.PackagesRootPath under Admin > Advanced Settings and move your files as needed, then it should work just fine.

Thanks,
Steve

Hi @kquinn_2909 ,

We haven't forgotten about this; the issue is trying to figure out steps to reproduce it based on the information we have... considering it works on our test instance and all. We may consider putting some more debugging code in, though figuring out how to expose that in this context is a little challenging.

Just as a sanity check though, do you have a project that doesn't have a "space" in the name? I want to make sure this isn't something really simple as WebProjects%20Replicator vs WebProjects_Replicator.

The other idea is authentication/authorization, though I would imagine you would get an error accessing the project instead of no builds.

Thanks,
Steve

Hi @jstrassburg_8563,

if the resolved version that npm i underscore chose was released in the blocking period, the npm command would 400?

If you have "Block Noncompliant Packages" enabled (which we generally don't recommend) and you have a rule that new packages are complaint, then the npm command would most certainly give some kind error.

You will probably see a 400 code, but I don't think it will display the message that's sent by ProGet (i.e. "package blocked due to...")? The real issue comes with a large dependency tree, and it'll be hard to know what exactly the issue is.

As such, we recommend running pgutil builds scan/audit in your CI/CD pipelines instead of blocking. This will produce a much easier to understand report, and even allow you to bypass issues reported on a case-by-case basis.

Thanks,
Steve

Hi @sigurd-hansen_7559 ,

Thanks for pointing me to the repository; I was able to reproduce this, and it will be fixed via PG-3194 in the next maintenance release (scheduled for Friday).

Thanks,
Steve

Hi @toseb82171_2602,

In Docker, images must have a namespace. When they don't, the Docker client will transparently append library/ to those namespaces. In general, this behavior is not desirable, and it's recommended to use library/python or, in a ProGet context, myproget.corp/mydockerfeed/library/python.

That said, there is a setting on the connector that may help resolves such images, but these images can be problematic even with that.

AS for extending the trial, no problem - you can actually do this yourself on my.inedo.com, on the day of expiry. Of course, please contact us if you run into any issues or have licensing questions.

Thanks,
Steve