Posts made by gdivis

Hi,

Thanks for reporting this. We've now fixed this internally as PG-2105 - it will be included in this week's 6.0.9 release, scheduled for Friday.

-Greg

Hi,

Thanks for the bug report! We've logged and fixed these as PG-2098 and PG-2099. Note that due to limitations in how that dependency table is built, it's nontrivial to have it take you to the latest package that satisfies the given range if it has an exclusive upper bound - but we have changed it to prefer linking to the upper version number if one is present.

-Greg

Hi,

Did the initial upgrade attempt fail, or did it appear to work but with the wrong directory?

What error did you get - are services/websites not starting?

-Greg

Hi @paul_6112 ,

That actually makes sense. We have an issue in our internal backlog to resolve high memory usage when a large number of agents are scanned just after an upgrade. I've published it as a publicly visible issue (BM-3758), and tentatively scheduled it for the next release.

-Greg

Hi @paul_6112 - The screenshot shows Inedo Hub v1.3.6. Was all of the testing done on this version? We did finally get a fix for this in Inedo Hub v1.3.7 (see DH-63), but did not confirm 100% that this was the underlying issue as we were not able to reliably reproduce it.

Thanks for passing along this test data!

-Greg

Hi @jcardos_9259

We now have this fixed in ProGet 6.0.2, which is scheduled for release on Friday. If you'd like to try the fix right now, you can install the inedo/proget:6.0.2-ci.3 Docker image.

Thank you!

Hi @shiv03_9800,

We've now fixed this issue as well. It is logged as OT-439, and will be included in the v3.0.14 release. If you would like to try the fix right now, you can use the inedo/otter:3.0.14-ci.1 Docker image.

Thanks,
-Greg

Hi Igor,

Thanks for the help in tracking this down. We've now fixed this in an internal build (logged as OT-428) . The fix will be in Otter v3.0.12, scheduled for release on October 8.

If you'd like to test a prerelease build, you can pull the proget.inedo.com/productimages/inedo/otter:3.0.12-ci.1 image, which already contains the fix.

-Greg

Hi Nico,

You're doing nothing wrong as far as I can tell.

I can't reproduce the issue where the wrong latest version is shown for an uncached package. Does it only happen for that one package? How many versions of it are on the external feed?

Regarding the other issue - that cached packages in the browse list may show the incorrect latest version - there is not much we can do about that. The browse list both in ProGet web interface and in the VS NuGet dialog sort by popularity and so frequently return totally different packages. The only way we could guarantee an accurate "latest version" display for cached packages on there would be to individually query those packages from the connector, which would drastically slow down the results. That said, I agree this isn't great. I'll chat with the rest of the team and see if we can come up with a better way to handle this.

-Greg

Hi Dennis,

Thanks for the feedback! You should be able to delete files/folders using the Asset Directory Delete API. Using curl, it should look something like this:

curl -X POST http://proget/endpoints/<AssetDirName>/delete/<path to directory>

We are actually focusing on Asset Directory improvements for the upcoming ProGet v6.0 release, so if you see any gaps or problems be sure to let us know!

-Greg

I've merged this pull request and published v1.0.2 with the change. Thanks for the fix!

I'm glad you got it working! I had forgotten that flag was even added :/

I'll chat with the docs team to get things clarified in there, or maybe see if we can change the default to enable v3 by default from now on.

Thanks!
-Greg

Hi,

Try using the NuGet v3 API for your feed instead- just use https://proget.eschbach.com/nuget/nuget-internal/v3/index.json as the package source URL in NuGet. NuGet's handling of semantic versions in the old API can be inconsistent, so this may resolve the issue.

Looks like that was our mistake, and we missed that line in the spec. This has now been logged as PG-1964, and it will be fixed in ProGet 5.3.30, scheduled for release on May 28.

Thanks for pointing it out, and sorry for the inconvenience!

Hi,

It looks like that file isn't a valid debian package file. According to the .deb file specifications, a file named debian-binary should be the first item, but instead, there's one named debian-binary/. You can see this by opening the file with a text editor:

Do you know what was used to generate the package?

We've got a fix for this as OT-415. It will be included in Otter v3.0.6. If you'd like, I can publish a prerelease version for you. Thank you!

@brett-polivka So one more update. Implementing the workaround was easier than expected. This should now be resolved in v1.11.1 of the Azure extension, which you install from the Admin->Extensions page. You may need to restart the Docker container after installing.

@brett-polivka It looks like the underlying problem is likely that 100MB limit. When we published the Azure extension, we'd mistakenly believed the maximum block size to be 4000 MB, but because we're using the v11 client library to push to azure, it's limited to the older 100mb limit. We can't upgrade without dropping support for .NET 452 on windows, which we aren't prepared to do yet, so we'll work around using another means.

We're on it; hopefully will have an update included for tomorrow's release.

That's strange. We'll do some experimentation with trying to perform that upgrade in a test environment and let you know what we discover.

Hi,

Could you click the "Submit Error Report" button when this happens? If you'd prefer to look at the file that gets set to us first, you can use "Save Error Report" instead. The error report is a zip file that should have more information than this empty log in it.

Thanks!

This is unfortunately a documentation issue. We changed some of the environment variable names for ProGet 5.3 - so you'll need to use:

-e PROGET_DATABASE="Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa;Password=<Secret>" \
-e PROGET_DB_TYPE=SqlServer

instead of -e SQL_CONNECTION_STRING=...

We'll update the docs to note this for ProGet 5.2.

Just following up- all of these issues should be resolved in ProGet 5.3.13, which will be released later today.

Thanks-

I've seen that anti-CSRF error appear if you try to perform certain tasks while not logged in- we're still investigating the cause.

Hi,

The lowercase file errors should be fixed in ProGet 5.3.13. So far we have not been able to reproduce authentication or activation issues, but we'll be adding additional logging in 5.3.13 to diagnose these issues.

Thank you!

We have identified the regression (PG-1830) and fixed it. It will be included in this week's maintenance release (ProGet 5.3.13), but you are also welcome to try the prerelease image right now if you would like - it's available as proget:5.3.13-ci.2 or progetmono:5.3.13-ci.2.

Thanks for reporting the bug!

This is not supposed to be the case. We'll investigate and try to reproduce this.

We've got this fixed. If you'd like to try it, it's available as proget.inedo.com/productimages/inedo/progetcore:5.3.12-ci.1

Docker uses different file operations from all of the other feeds, so it looks like we missed fixing it there. We'll look into this and get it fixed.

Thanks for trying progetcore!

Thanks for the detailed writeup! We've just published v1.0.1 of pgscan that should fix the issues you've described. v1.0.1 will now actually write errors and other info to the console like it's supposed to. There is also now a --api-key argument to allow it to authenticate with ProGet.

Downloads are here: https://github.com/Inedo/pgscan/releases

Thanks for the error report. We've fixed this as PG-1816, which will be included in tomorrow's releases (ProGet 5.3.11).

Hi Simon,

Thanks - we'll include tzdata in the image starting with ProGet 5.3.7, scheduled for release on July 17.

Windows extension v1.6.3 is now released, and it fixes this problem. Thanks for the bug report!

Hi Philippe,

I have confirmed this is a bug in the Windows extension. I expect we will have an updated version published tomorrow.

Thanks
-Greg

Hi Philippe,

Thanks for reporting this. I've logged it as OT-379, and it will be fixed in Otter 2.2.22, which is scheduled for release in a week (June 26).

We've clarified the instructions for mounting the packages volume. In short, both formats will persist packages beyond the container's lifetime, but if you already have packages stored somewhere, you'll need to mount that directory (as you discovered) instead of using the "proget-packages" Docker volume.

Hi,

It looks like this is indeed an issue with the Content-Length header not being set properly when ProGet is running as a Linux container. I've logged this as PG-1740.

This is logged as PG-1711, and will be fixed in ProGet 5.3.1.

Thank you!

It looks like the "latest" tag didn't get updated properly for some reason. I've triggered another rebuild on it, and it refers to the correct commit now.

Looks like there was an issue with our deployment and the Postgres updater got left out of the Docker image. I've pushed a new one, so if you re-pull the 5.2.30 image, it ought to work.

This is now fixed as of Inedo Hub 1.0.23.

Hi @markcodyre_7146 - we now have a prerelease version of ProGet available with support for RPM feeds. It is currently lacking support for connectors, replication, and GPG keys but otherwise is ready for testing if you'd like. It’s available now via InedoHub as ProGet 5.2.25-redline.1.

Hi,

Thanks for letting us know. Looks like the error message is wrong - actually the problem is caused by build metadata being present in a version number that is not a semver2 version.

We've filed this as PG-1655 to make parsing these versions more permissive - it will be fixed in the next ProGet release (5.2.23), currently scheduled for Jan-17.

It looks like this was caused by a change in our internal deployment process. I've logged this as PG-1615, and it will be fixed in ProGet 5.2.14, which is scheduled for release on Friday (October 18).

Thanks for the report!

We've now reproduced this, and it turns out there's a regression in 5.2.13 with how config files are read which determine whether to use SQL Server or postgres. We have implemented a fix as PG-1614, which will be included in ProGet 5.2.14 (scheduled for release on Friday, October 18).

For now, I'd recommend just reverting to 5.2.12 until the next version is available.

Thanks to all who reported this!

Just a quick update- I realized our upgrade instructions are wrong. If you're using SQL Server, you'll need to specify the database type and the connection string with the docker run command: (see the updated instructions here: https://docs.inedo.com/docs/proget/installation/installation-guide/linux-docker)

Hi,

I've tried to reproduce this in a few different ways, but it seems to work for me. What are the exact arguments you're passing to docker run?

Hi Martin,

This will be included in this Friday's (Aug 23) release (5.2.9).