Posts made by felfert

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