Proget 2025.3
With universal packages - in the usage instructions, the 'group name' gets repeated twice in the usage instructions, in all 3 tabs, upack client, cURL and PowerShell:
Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Proget 2025.3
With universal packages - in the usage instructions, the 'group name' gets repeated twice in the usage instructions, in all 3 tabs, upack client, cURL and PowerShell:
@phopkins_6694 - I've successfully used "delete all versions" in 2025.3 - but on an NPM feed rather than Choco. However I pressed the "Delete Package" button from your second screenshot rather than the "Delete Specific Version..." button that you have highlighted.
Hi @atripp,
One of the uses for upacks for us, is for storing binary images for things that are subsequently included into other CI builds. These are usually things are are not updated particularly frequently, and are not built by our CI system, for example an FPGA image, or perhaps some binary image provided to us by a component manufacturer.
So the process to update these packages is generally manual - we could use pgutil, but the UI seemed like a really nice feature. It's great for creating the first version of a package, but it just seems a bit awkward when adding a new version of an existing package, as you have to carefully re-enter the group and package name to match the existing package. So having a shortcut on the package page to add a new version of a package with the group and package name pre-filled would be really helpful.
ProGet 2025.3
On the Tasks / Permissions screen, sometimes (probably when there are an even number of rows in 'scope'). Due to the alternating shading, it's not possible to see where the divide should be between different task names:
A user with only 'Publish Packages' permission can't clear at least some ProTips. When they click the close icon on the ProTip, the error is displayed: "<username> is not permitted to perform the Admin_ManageFeed task for the current scope."
ProGet v2025.3 - Basic Edition
Since upgrading from 2024.36 to 2025.3 the user interface to allow universal packages to be created is no longer available for users with "Publish Package" permissions/task. Note this the default 'publish package' task - completely unmodified. Seems to apply to all feed types - but haven't extensively tested it.
2024.36:
2025.3:
I've made a bit of progress on this problem. I've now moved up to ProGet 2025.3 - and the image now does have lots of locales available (maybe they were there before, but I hadn't discovered how to enable them).
To enable specific locales it is necessary, it seems, to uncomment the appropriate lines in /etc/locale.gen, and run the locale-gen command.
It's then possible to set LC_TIME to this locale, and now when you send the date command it is formatted in the selected locale.
To achieve this i've added the following to my docker-compose.yml:
entrypoint: sh -c "sed -i 's/# en_DK/en_DK/' /etc/locale.gen && locale-gen && /entrypoint.sh"
environment:
LC_TIME: "en_DK.utf8"
However - having done all that - The ProGet UI doesn't actually format the dates in the system locale of the container.
It would be handy to have a way to access the UI to create a universal package via the package's page. The package group and package name could therefore be pre-filled, to avoid having to cut and paste it, or for a mistake to be made in the name of the group or package. (same workflow as using the create package UI from the feed page)
I've just used "pgutil packages repackage" to change the versions on all my erroneously versioned packages from w.x.y.z to w.x.y-ci.z.
I was expecting only to see the newly versioned packages, but in fact i now have both versions listed - is this the intended / expected behaviour?
Also, i'm not seeing anything in the history tab to show that the package has been repackaged. But I can see the 'repackageHisory' in the upack.json.
ProGet version 2024.36 (build 5) - Trial license (Basic Edition Features)
@stevedennis - I'm migrating items from another system, and we do use 4-part version numbers (where the 4th is the build number). But we don't want it to ignore the build number part. Combining parts 3 and 4 isn't very pretty, and won't give a very good first impression of ProGet to my users if I say that that's not supported.
I'll look into going do the -ci.xxx route - I assume it will order them alphabetically rather than numerically though - so i guess i need to pad them with 0's to the maximum likely width.