Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @gravufo,

Would you be able to rerun the database scripts on your database? You will just need to run the Run inedosql to update the database step of our manual install guide. Can you see if this fixes your issue?

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.

Thanks,
Rich

Hi @mcascone ,

We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.

Thanks,
Rich

Hi @viceice,

Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.

Thanks,
Rich

Hi @markus4830,

I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich

Hi @harald-somnes-hanssen_2204,

The fix is scheduled for release in ProGet 5.3.16 which is due out on Friday. I'll reply back if anything changes.

Thanks,
Rich

Hi @tkolb_7784,

If you are hosting on a windows machine, the easiest solution right now is to migrate your server to use IIS and then add an SSL binding to your site. If you do not want to purchase a new certificate and the self-signed certificate is too much work, you can use Let's Encrypt and configure it via winacme.

If you do not want to use IIS, then you will need to use a reverse proxy to handle SSL connections. Any reverse proxy can be used and a pretty simple one to configure is stunnel. Most reverse proxies can also be used with Let's Encrypt.

If you are hosting via Linux (Docker), then you will need to use a reverse proxy to handle SSL connections. We have a documentation page for different Linux-based reverse proxies including an example for setting up NGINX. These reverse proxies also support Let's Encrypt also.

Please let me know if you have any questions.

Thanks,
Rich

Hi @barnaby-williams_8489,

Please see our documentation for cloud storage. There is a subsection for migrating a feed to cloud storage.

Thanks,
Rich

Hi @aristo_4359,

Thank you for sending that over. I have recreated the issue and created PG-3116 to track the fix. We should have this resolved within the next two maintenance releases of ProGet.

Thanks,
Rich

Hi @aristo_4359,

Is this all rpm packages or just specific versions of a package? Can you share package names and version on the ones that will not delete?

@aristo_4359 said in RPM Bulk Edit Delete does not work:

Also a suggestion, when user delete package the page ideally stay on same page, instead redirecting to main feed on deleting single package and redirecting to first page when deleting using bulk edit

Thanks for the suggestion. The reason we redirect to the feed page after deleting a single package is because we don't know if the package will still exist (has other versions and/or is a remote package) in that feed. Although it is not trivial to check before we redirect, it could be added. I am going to add this to the list to discuss for ProGet 2026.

Thanks,
Rich

Hi @m-ruf_4197,

Sure thing! I have added ticket PG-3115 to track the feature. It should be released within the next couple of maintenance releases of ProGet.

Thanks,
Rich

Hi @caterina,

Good catch! We'll get that fix merged in.

Thanks,
Rich

Hi @windowsteam_8276,

Thanks for bringing this to our attention. We just pushed Otter 2025.1 that includes a fix, Ot-522, for that issue. Please upgrade to that version and let us know if that resolves the issue. Thanks!

Thanks,
Rich

Hi @inedo_1308,

I have just published a new CI build that should fix your issue. If you upgrade your Docker container to ProGet 25.0.8-ci.3, that should fix the problem with your feed usage instructions.

Thanks,
Rich

Hi @layfield_8963,

I'm having trouble recreating this error. I just stood up a clean install of ProGet 2025.7, created an asset directory, and uploaded a file to it. I then ran the command you sent and this is what I see:

pgutil.exe assets metadata set custom --path=test.txt --feed=test-import-data --key=test123 --value=12345
Setting test123 = 12345 on test.txt...
Metadata set.

Can you please navigate to Administration -> Software Info and copy and paste the contents of that here? If you feel more comfortable, you can email it to support@inedo.com with the subject [QA-2790] Database Information. If you email it, please let us know when you do so we can look for it in that mailbox. The only thing I can think of is that your database schema did not update properly on upgrade.

Thanks,
Rich

Hi @inedo_1308,

@inedo_1308 said in ProGet bug - Duplicate custom Feed Usage Instructions for Debian feeds:

Actually this feature (signed-by) is quite old. It just was badly documented for a long time (See this question) and therefore nobody used it.

Thanks for the additional details!

@inedo_1308 said in ProGet bug - Duplicate custom Feed Usage Instructions for Debian feeds:

I would appreciate that very much :-)

No problem, I'll reply back as soon I as I have a build ready.

Thanks,
Rich

Hi @layfield_8963,

Just to verify, is your instance using SQL Server or PostgreSQL? Also, can you please provide me the command you are using to recreate that issue? That will allow us to more quickly identify the issue.

Thanks,
Rich

Hi @inedo_1308,

I updated the name on that ticket. It will also cause other issues with other feed types as well. It is an issue with how it creates usage instructions that have the same name as other usage instructions (both built-in and custom). As part of that ticket, we will handle fixing the editing and deleting of instructions that were created incorrectly. The display issue will most likely need to be fixed by manually deleting the duplicates and recreating them (post fix).

I will also fix the Debian usage instructions as well. Since I'll be touching the code where the built-in instruction is stored, I was planning to just include them in that ticket, but I can create a new ticket for that as well. When we wrote our documentation for Debian, signed-by was not a feature yet. In the latest updates for the updated Debian feed, most customers were still using the legacy way for adding ProGet as a source. It has really only been in this latest major of apt that signed-by has worked consistently for us.

I plan to work on these early this week. If you want, I can provide you with a CI release as soon as these are ready if you want to test them early.

Thanks,
Rich