Posts made by felfert

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

In the latest updates for the updated Debian feed, most customers were still using the legacy way for adding ProGet as a source.

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.

So, for ubuntu, it should work since 16.04. On older systems however, the directory where the keys are to be stored did not exist and the recommended path of that directory changed over time.
The implementation in apt works with any directory (as long as it is readable by apt).
Therefore, a slightly modified command for downloading/generating of the key file should help (first line of existing instructions) like this:

Old:

curl -fsSL http://my.proget.dom/debian/my-repo/keys/my-repo.asc | sudo gpg --dearmor  -o /etc/apt/keyrings/my-repo.gpg

New:

sudo mkdir -p /etc/apt/keyrings; curl -fsSL http://my.proget.dom/debian/my-repo/keys/my-repo.asc | sudo gpg --dearmor  -o /etc/apt/keyrings/my-repo.gpg

This should work even on older systems.

Sorry I forgot to mention that in the first place.

Cheers
-Fritz

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

Hi @inedo_1308,

Thanks for sending this over to us. I created a ticket, PG-3069, to fix the exception with editing. I'll also get the feed usage instruction and our documentation updated with the signed by parameter.

Thanks,
Rich

Hi Rich,
I just looked at the ticket you created and I think, I was not clear enough in my description.
(I can see the ticket title only, so forgive me, i I'm overly pedantic :-)

• The original culprit is that the "Duplication" actually does not duplicate but triples the description in the first place. The following error/exception (not being able to edit) is just a logical consequence.
• Furthermore, this happens with debian feeds only.

Also: the actual reason for always requiring custom instructions is, that the built-in instructions are missing an important detail:

Existing example (2nd line):

echo "deb http://...

should read:

echo "deb [signed-by=/etc/apt/keyrings/key.gpg] http://...

where key.gpg is the name of the key generated by the first line.

I remember that already being reported here by another user in the past.
Maybe you can change the builtin instructions, so that the custom edit is not necessary anymore.

Cheers
-Fritz

I first noticed this in 2025.2 and still happens after updating to 2025.6:

How to reproduce:

1. Create a new debian feed
2. In the feed properties, click on the link "Integrate with apt (built-in)"
3. Click on the link "duplicate this instruction" at the top (or the "Duplicate" button at the bottom.
4. Click on the "Save" Button (no need to change anything before that)

Result:
The duplication happens twice, resulting in a total of 3 Feed Usage Instructions.
After that, clicking on any of the 2 "duplicated" instances in order to edit it, triggers the following error dialog:

(500) Server Error
Sequence contains more than one matching element

For more information, visit the Error Log Page.

The error log shows the following:

An error occurred in the web application: Sequence contains more than one matching element

URL: http://proget.graudatastorage.intern/feed/edit-usage-instructions?feedId=28&feedUsageInstructionId=14&duplicate=False
Referrer: http://proget.graudatastorage.intern/feed/manage?feedId=28
User: felfert
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0
Stack trace:    at System.Linq.ThrowHelper.ThrowMoreThanOneMatchException()
   at System.Linq.Enumerable.TryGetSingle[TSource](IEnumerable`1 source, Func`2 predicate, Boolean& found)
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at Inedo.ProGet.WebApplication.Pages.Feeds.CreateOrUpdateFeedUsageInstructionsPage.CreateChildControls() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E578130\Src\src\ProGet\WebApplication\Pages\Feeds\CreateOrUpdateFeedUsageInstructionsPage.cs:line 30
   at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync() in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E578130\Src\src\ProGet\WebApplication\Pages\ProGetSimplePage.cs:line 70
   at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
   at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
   at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

::Web Error on 07/30/2025 10:30:28::

So: The custom instructions can not be edited anymore. Deleting one of them deletes both.

Note:
DB is postgres (was migrated after v2025 was released), running in a docker container

Regards
-Fritz

Hi,

I know this is experimental Hopefully this helps you guys improving this cool feature.

I was testing proget in a podman/quadlet environment running on a virtualized Rocky9 (RHEL9 clone). First startup with mssql and migration to postgres went well and everything worked so far. However when the container is stopped&destroyed and then recreated, the postgres process does not startup.

I made the following observations:

• Initially, the postgres db is created in (/var/proget/packages/database) and it belongs to uid/gid 101/104 which matches postgres/postgres inside the container. Also the special files .preferpgsql and .pgsqlconn are created.
• When the new container instance is starting, this changes ownership of the whole hierarchy to root/root which then - obviously - cannot be used by postgres anymore.
• Either the postgres process is not startetd at all, or it terminates immediately.
  Consequently, proget complains in the log like this:

Cannot connect to database; will retry in 1 second... Full error: Failed to connect to 127.0.0.1:5728

• I can remedy the situation manually by running the following (first line enters a shell inside the running container, rest runs inside the container):

podman exec -it systemd-proget /bin/bash
chown -R postgres:postgres /var/proget/packages/database
rm -f /var/proget/packages/database/postmaster.pid
su -g postgres postgres -c ". /var/proget/packages/database/postmaster.opts"

My conclusions:

• The existence of /var/proget/packages/database/postmaster.pid suggests an unclean termination of postgres
• The change of ownership of the db directory during startup should be fixed. Perhaps it would be wiser, NOT to use a subdir of the packages, but a separate volume.
• Is there an attempt to start the postgres process at all?

Cheers
-Fritz

Forgot to mention the image i used:
proget.inedo.com/productimages/inedo/proget-postgres:24.0.37-ci.2

Many thanks, Alana!

I can confirm, that the proget:24.0.37-ci.2 container image works like a charm

Thanks for the quick fix!

• Fritz

Just tried migration of an old legacy Debian feed to a normal Debian feed. No errors were reported during the migration and in proget's web-UI, everything looks fine. However the feed is unusable with apt on any distro.

When running apt-get update (or apt update), it complains about the Packages file not being parsable like this:

Reading package lists... Error!
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/proget.graudatastorage.intern_debian_XTC-deb_dists_jammy_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.

If I look at the file mentioned above, It turns out, apt is correct in that there are multiple errors:

• Each package record MUST begin with the Package: field. Proget puts this field in between the other fields.
• Between the Size: field and the Filename: field, Proget puts an empty line which does not belong there. Empty line are reserved as record separators.

I also noticed some inconvenience with the Migration itself:

When migrating, proget uses the name of the legacy feed as Distro for the new feed. So if I want one of the usual Distro names (e.g. like bookworm), then I have to rename the old feed accordingly before starting the Migration. This might impact availability. It would be easier, if the Distro name could be entered manually when starting the migration.

Proget version: 2024.36 (Build 5) running in a docker container
Cheers
-Fritz