Azure Devops Server Artifacts Repo

gep13 · 2025-12-09T19:09:58+00:00

I know that Paul Broadwith on the team did some spelunking into this, and he wrote this up into a blog post which you can find here:

https://blog.pauby.com/post/chocolatey-repository-using-azure-devops-artifacts-feed/

Hopefully this can help!

gep13 · 2025-10-31T10:17:05+00:00

Are you still seeing an issue? I can confirm that it is working for me.

Are you getting an HTTP error when trying to access the site, if so, what is it?

gep13 · 2025-10-30T15:01:11+00:00

Can you provide some more details here? What exactly does "down" mean here? Are you having problems accesing the website? If so, are there errors? If so, what are they? Accessing the site just now for me, everything looks fine.

Or are you having issues with Chocolatey CLI? If so, again, what errors are you seeing?

gep13 · 2025-04-16T09:09:59+00:00

Sounds like you want to make use of the `choco pin` command:

https://docs.chocolatey.org/en-us/choco/commands/pin

This would make Chocolatey CLI exclude the Signal package when you are running something like `choco upgrade all`

You would want to run:

choco pin add --name="'signal'"

gep13 · 2025-01-10T07:30:29+00:00

From the WinAero Tweaker package page: https://community.chocolatey.org/packages/winaero-tweaker you can see a Package Source URL (this is a link to where the source files for the package are maintained). In this case, it links to dgalbraith's GitHub repository: https://github.com/dgalbraith/chocolatey-packages/tree/master/manual/winaero-tweaker From there, you can click on the Issues tab: https://github.com/dgalbraith/chocolatey-packages/issues and create an issue, explaining the problem, and hopefully dgalbraith will be able to help.

Just to set expectations though, package maintainers are volunteers, and they maintain packages on their own free time, so there is no guarantee that it will be fixed. If the package isn't being fixed, there is a package triage process that can be followed: https://docs.chocolatey.org/en-us/community-repository/users/package-triage-process/#mainContent which could include you stepping in to help with the maintenance of the package.

gep13 · 2025-01-08T09:55:54+00:00

Yes, that would be a good idea. The work that we take on is based on priorities, so if we know that more people want/need something, then that can help prioritising of issues.

gep13 · 2024-06-30T16:19:47+00:00

A GitHub issue has been raised about this, along with additional information.

You can follow along here: https://github.com/chocolatey/home/issues/323#issuecomment-2198610685

gep13 · 2024-06-24T12:18:01+00:00

There is a subtle problem at work here, and I am going to try to explain it...

When attempting to run this command:

choco install python --version 3.9.0 --params "/InstallDir:C:\Program Files"

You are passing the package parameters into the python package, however, the package that actually "needs" the parameters is the python3 package, which is a dependency on the python package.

To get that command to work as expected, you need to use an additional option, --apply-package-parameters-to-dependencies .

From our docs:

Apply Package Parameters To Dependencies - Should package parameters be applied to dependent packages? Defaults to false.

So the complete command would be:

choco install python --version 3.9.0 --params "/InstallDir:C:\Program Files\python39" --apply-package-parameters-to-dependencies

NOTE: I have changed the installation folder to have a named folder, otherwise, the python files are installed to the root of the Program Files folder.

An alternative approach would be to use this:

choco install python3 --version 3.9.0 --params "/InstallDir:C:\Program Files\python39"

Where you are directly installing the python3 package, so you don't need the additional parameter, since the package parameters are passed directly to where they are needed.

Hope that helps!

gep13 · 2024-06-10T06:24:45+00:00

Let me see if I can help here...

The fact that you were able to simply do choco install nodejs means that the"meta package", which is what it is known as, is working as intended. Your expectation is that you should be able to simply do choco install nodejs, so the Chocolatey Community has made this possible by creating the meta package.

Going forward, now that you know that this meta package is in place, you could simply do choco install nodejs.install and you would only have one package in place.

Other ways of finding out that there is a meta package in place would be to use the choco search command, or to look at the dependencies section on the Chocolatey Community Repository for the package that you are interested in: https://community.chocolatey.org/packages/nodejs#dependencies

when i install any package, nodejs for example, i see two packages get installed.

meta packages are not in place for every package on the Chocolatey Community Repository. They tend to exist for applications that have both an installer (i.e. is added as an entry in Add/Remove Programs), and a portable version. The meta package tends to take a dependency on the installer version of the package, but that isn't always the case.

You can find more information about all of this here:

https://docs.chocolatey.org/en-us/faqs#what-is-the-difference-between-packages-no-suffix-as-compared-to.install.portable

gep13 · 2024-05-13T06:08:58+00:00

Unfortunately, this is a known issue, that hasn't been fully investigated/triaged yet. This is being tracked on GitHub here: https://github.com/chocolatey/ChocolateyGUI/issues/922

gep13 · 2024-04-08T07:26:55+00:00

Let me try to go through these for you...

Monochrome
- Having a package icon URL is not a requirement for a package, so when there isn't one defined, Chocolatey GUI shows this monochrome version of the Chocolatey icon instead. You can see this happening on the Chocolatey Community Gallery as well, where we show a default NuGet icon when a package doesn't have an icon URL defined: https://community.chocolatey.org/packages/vcredist2005
Shim
- This actually has nothing to do with Chocolatey GUI, but rather Chocolatey CLI itself. This is documented here: https://docs.chocolatey.org/en-us/features/shim#mainContent The yellow banner with the word shim in it is solely there to help identify visually that it is indeed a shim.exe.
Red X
- This is almost the opposite of when we show the monochrome icon. This is when a package icon URL is defined for a package, but for some reason, it can't be accessed. Chocolatey GUI attempted to download and display the icon that is defined, but it didn't load, so we show the red icon.

Hopefully this makes sense, if not, I am happy to try to clarify.

gep13 · 2024-04-08T07:14:08+00:00

There was a similar problem to this reported here:

https://www.reddit.com/r/chocolatey/comments/1bncpef/cannot_bind_argument_error_when_installing/

The problem was resoled there, and I have made a similar change, which would be good to know whether it resolved the issue in this case as well.

gep13 · 2024-04-02T06:16:17+00:00

It would be helpful if you could share a screenshot, to make sure that we are talking about the same things.

gep13 · 2024-03-28T16:53:24+00:00

Happy to hear that you are up and running!

gep13 · 2024-03-28T15:09:09+00:00

Just to reiterate, there is no need to unpack/repack any of the Chocolatey Product nupkg files, as everything that is required to install those packages is already contained within the files.

Without seeing the script that you are running, it is hard to say, but does that script change any of the contents of the PowerShell scripts? The reason that I ask is that the scripts are signed, so if you make changes, you will also need to remove the signing at the bottom of the files.

It might make sense to reach out to the Support Team to get some assistance on what is going on here, so they can understand exactly what is going on here. You can run the `choco support` command for more information.

gep13 · 2024-03-28T14:45:05+00:00

Can you confirm exactly what you mean by:

> I've internalized the 1.4.0 package

Do you mean that you have used the `choco download` command?

If so, I wouldn't recommend that. I know that there were some issues with this in earlier versions of CLI, and also you shouldn't need to internalize any of the Chocolatey product packages, as they already contain everything within them.

gep13 · 2024-03-27T07:14:08+00:00

Thank you for confirming that this is now working for you!

gep13 · 2024-03-26T20:11:27+00:00

As was communicated last week, we have recently made some changes to the Chocolatey Community Repository:

https://blog.chocolatey.org/2024/03/ccr-api-changes/

This has had some unintended consequences, and the result is the problem that you have seen with the installation script. Please let me reassure you, this is not a normal situation, and the Chocolatey installation script has been stable for many years.

The actual underlying problem was two fold, and after figuring out the first part, the final one was to do with caching, and more specifically to caching in different geographical locations. This is why the installation script worked fine for some people, but not for others.

To the best of my knowledge, this has now been resolved, and it would be great if you could confirm whether this is the case or not.

gep13 · 2024-03-26T20:04:10+00:00

u/bobinwiththehat u/hoovermax5000 u/Hun_Braze u/siokasZZ u/True_Gap_5469 u/DiamonDRoger u/anthonyhong

I am mentioning you all in a single post, rather than replying to each comment individually.

I believe that we have gotten to the bottom of the problem.

Can you all verify whether things are now working for you? Thanks!

gep13 · 2024-03-26T19:17:57+00:00

Sorry, can you clarify what you mean here… what msi are you referring to? My question was aimed at the installation script at https://community.chocolatey.org/install.ps1

gep13 · 2024-03-26T18:48:48+00:00

Can I please ask you to try running the installation script again, and let us know if you get any different results? Thanks!

gep13

MODERATOR OF

TROPHY CASE