administrators

Hi @matthias-reitinger_3646,

Good catch and thanks for sending over an example! I took a quick look and you are correct that bin was not included in the metadata for that package. I have created a ticket, PG-3000, to track the fix for this. Unfortunately it is too late to get this fixed in today's ProGet release, but it should be fixed in the next maintenance release of ProGet, 2024.39, which is expected in two weeks.

Thanks,
Rich

Hi @michal-roszak_0767 ,

I'm afraid Feed Groups are not currently supported in the Feed Management API or pgutil feeds commands. We are considering rewriting/refactoring the API later this year, so I've added this to the notes to consider for that.

Thanks,
Steve

@dimas thanks for that!

We're currently studying/monitoring the performance for public mirroring, and one "concerning" thing I recently saw was a sqllite3 index file explode in file size. We don't know how that happened, but suspect it might have to do with some "aggressive" testing / request cancellation.

Let us know if you spot anything:

https://forums.inedo.com/topic/5410/debian-feed-mirror-performance

Hey @dimas ,

Ah, that makes sense. Looking at the manifest files, they have the same Identity@Id (which is what ProGet uses for the Package Name) but a different Identity@TargetPlatform (which must be new-ish):

<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

We could probably figure something out in ProGet, but it's not trivial when it comes time to changing how we identify Package Names.

Can you try editing the manfiest file inside the vsix archive, and seeing if that works for your use case?

So basically:

<Identity Language="en-US" Id="python-win32-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="win32-x64"/>
<Identity Language="en-US" Id="python-linux-x64" Version="2025.2.0" Publisher="ms-python" TargetPlatform="linux-x64"/>

Not quite sure if that would work, but figure it's worth a try.

Thanks,
Alex

Hi @misael-esperanzate_5668 ,

I'm not really sure, but I'll explain how things work so it might help troubleshoot.

First, the Maven API does not provide a file listing. While you (as a user) can often "see" via an HTML page (like this listing at jboss.org), it's simply not available for listing in the API. The only required file in an artifact is the .pom file, so when you "pull" an artifact to ProGet, that's all you'll get.

Next, the "remote" icons next to the files indicate that they were cached (i.e. added to the feed) via a connector. That means the files were successfully written to disk, recorded in the database... but now they are gone. Hence, why you keep getting the "file not found" message.

The most likely culprit for this is something deleting the files from a packagestore. We often see security tools doing that for "safety" reasons, since they are .jar files that may be dangerous I guess.

Overall, the maven API is a very simple series of GETs. So perhaps, you can just experiment with this? First, start with a brand new feed and a connector.

Then, run the command:;

curl http://my.server.local:8624/maven2/my-new-feed/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar --output hamcrest-core-1.3.jar

You should see the file download via CURL. Afterwards, you should see the artifact as a cached package (Top Navigation > Packages > Select Cached). You should also see that .jar file on disk, written to the package store location (Manage Feed > Storage).

If you don't see a .jar file downloaded to that location on disk, then it means something is "blocking" the file being written. If it's there, then it means something is deleting it after.

Thanks,
Alana

Hi @layfield_8963,

Looks like this was just a simple bug preventing output from being written when stdout has been redirected. It's now fixed in pgutil 2.1.1.

Thanks for the update!
-Greg

Hi @rel_0477,

Thanks for sending over the reproduction case. I was able to identify the issue, PG-2993, and have it ready to go in the next maintenance release of ProGet.

Thanks,
Rich

@michal-roszak_0767 sorry, this is definitely sub-optimal and needs work

Basically, when you have API Key Hashing available, there's no way for the page to filter the incoming requests. So, all of the items are shown. It's not really a trivial to fix and requires us to rethink a bit how we are storing/logging this data. We can explore revisiting as part of ProGet 2026.

@dimas said in Incomplete proget debian connector local index file for ubuntu noble-backports dist:

why does the proget connector omit empty repository components altogether, instead of making them empty like virtually every other Debian repo?

Most other Debian repos use or fork Dpkg to generate the folder structure based on files on disk.

ProGet doesn't. Instead, we parse/index all packages in the repository in a local sqllite3 database. That database has a "Packages" table, and we use that to generate feed indexes (Release, InRelease). It's possible to change, and involves modifying the sqllite3 databases to add a Components table, and then changing the way we generate all the indexes.

It's not too hard but it's not trivial and probably isn't worth it unless we get more feedback on the matter.

Thanks,
Alex

Hi @dimas ,

It looks like VSCode still doesn't support private galleries. I know users have been requesting it for over eight years now.... so maybe it'll come soon! But until then, we can't implement it in ProGet.

I'm not sure what you mean about the python extension... but I do know that a visx file uses some kind of GUID to uniquely identify an extension. If the different "versions" of python visx use that same ID/Version, then I suppose it would get overwritten.

Alex