Arch Linux User Repository

@dbb Thanks for the report. I wasn't aware of that bug... I'll have a look and see what it will take to fix it. Having the extra path (or the config working) would be nice to have. I wanted to continue working on building the modules tomorrow, then I'll also investigate that one. Since it's an issue in the core, I would ideally want to get that upstreamed. I'll try the same with the manpage fix. The /tmp/Microsoft.PackageManagement/ issue is something we'll probably never get to see fixed, since OneGet does not accept pull requests anymore. :/

Thanks for the update. Getting the following error running the shell:

$ pwsh -noprofile
PowerShell 7.6.3
The shell cannot be started. A failure occurred during initialization:
Index was out of range. Must be non-negative and less than or equal to the size of the collection. (Parameter 'startIndex')

Root cause seems to be 20706. Editing /etc/powershell.config.json to not include a path separator allows it to start. Seems like a long standing regression, may be simplest to patch it?

I just pushed a huge update. This took me quite a while. I have written a lengthy commit message about all the improvements, but let me give you some highlights from that here:

1. ReadyToRun is now working correctly, speeding up start times of pwsh significantly. There will be a noticeable increase in package size. This is due to the precompiled R2R code being added to the binaries.
2. xUnit test are now being run as well
3. Telemetry is now stripped out. I discovered a nifty way to eliminate the various calls to the Telemetry.cs implementation, and thus we now remove that file and don't even link ApplicationInsights anymore. You can try calling [Microsoft.PowerShell.Telemetry.ApplicationInsightsTelemetry]::get_CanSendTelemetry() and it will just print out a type error now.
4. /etc/powershell.config.json is now available and in the backups array. See about_PowerShell_Config for more info.
5. With that config, a default one is installed that adds /usr/share/powershell/Modules in addition to the regular /usr/local/share/powershell/Modules as module path. This gives a convenient install path for Modules from packages.
6. pwsh(1) man page now included, and - it's fixed. Upstream's has been broken for years now.
7. The Get-Help content for PowerShell itself is now included. It's rarely updated and this way the files are tracked with proper permissions. Before, if an admin updated them, they wouldn't be world readable.
8. Pester 4 is now not accidentally packaged anymore. I did replicate the whole upstream packaging logic, so other files that shouldn't have been shipped are now filtered out as well.

Then, I've also uploaded DSCv3 and PowerShellEditorServices to AUR. Both are making use of this new /usr/share functionality, and PSES is specifically optimised and features R2R for faster startup unlike the official binaries.

Update: I found a way to fix the horrible /tmp/Microsoft.PackageManagement/ permissions problem in OneGet (aka Microsoft.PackageManagement); the thing that provides Install-Module but hasn't been developed in years. It's this issue I'm referring to. Every invocation of OneGet will attempt to create that folder at the start. The problem is, that this applies for every user, so the first user after a boot to use OneGet blocks it for all others. After some investigration, it turns out the culprit is a simple logic error, in this line. The appTempPath it wants to use is a combination of OriginalTempFolder, which is initialised to Path.GetTempPath(), and the assembly name, Microsoft.PackageManagement. On Windows, Path.GetTempPath() returns the users temp folder, %userprofile%\AppData\Local\Temp, but on Linux it's /tmp. Alas, on Windows this is isolated per user, but on Linux it's global, causing the problem.

This is easily fixed by making it use XDG_RUNTIME_DIR instead, which would be /run/user/<userid> and is isolated per user. That's a one line fix, but it will require me to look at building the dependent modules like OneGet, PSReadline, etc. They're all open source, so there's no real reason to download prebuilt binaries off PSGallery for them, when we can just build them from source. Getting that set up will take a bit of time though. It's made easier because by the time we'd need to build them, PowerShell is already built and so we can just use their native .ps1 / .psm1 build scripts instead of having to do this all from scratch. Shouldn't be too much work, because the string handling to fix up the build systems and make them work with current tools (like adjusting the nuget config, csproj files (TargetFramework and friends) is much easier to do in PWSH than with sed, awk and friends. So, I'll be moving the increasing number of powershell blocks in the PKGBUILD into our own little .psm1 that will handle the Pester testing - this would also be needed for the tests the dependent modules ship with - and building those modules. That will be much easier to read than embedded powershell code in a PKGBUILD :D

@B3l3tte The test case itself creates that file. I'm just not sure how it broke for you, but maybe run New-Guid in your pwsh binary to see if that generates proper UUIDs.

As for the patch: It probably looks weird in diff as you're looking at the diff of a diff, so to say. The patch applied is this.

The way that code segment works that if CanSendTelemetry evaluates to false, the telemetry is never set up, as it exits here. Now for that variable itself: It is set to true if POWERSHELL_TELEMETRY_OPTOUT (via the constant _telemetryOptoutEnvVar) is not set to true and it can find the location where the telemetry.uuid file would reside. Utils.GetEnvironmentVariableAsBool() returns the value of POWERSHELL_TELEMETRY_OPTOUT, or defaultValue if that variable is not defined in the environment. My patch changes that default, flipping it from false to true. Effectively, this means that if POWERSHELL_TELEMETRY_OPTOUT is not set, it will be treated as if POWERSHELL_TELEMETRY_OPTOUT=1 instead of POWERSHELL_TELEMETRY_OPTOUT=0. For this reason, explicitly setting POWERSHELL_TELEMETRY_OPTOUT=0 overrides the patch as well.

You can verify that this works by observing that telemetry.uuid file btw: It will be created as ~/.cache/powershell/telemetry.uuid for each user if and only if PowerShell is started with telemetry enabled. As you can see this now works as expected:

sh-5.3$ ls .cache/powershell/telemetry.uuid
ls: cannot access '.cache/powershell/telemetry.uuid': No such file or directory
sh-5.3$ pwsh -noprofile -command "exit"
sh-5.3$ ls .cache/powershell/telemetry.uuid
ls: cannot access '.cache/powershell/telemetry.uuid': No such file or directory
sh-5.3$ POWERSHELL_TELEMETRY_OPTOUT=0 pwsh -noprofile -command "exit"
sh-5.3$ ls .cache/powershell/telemetry.uuid
.cache/powershell/telemetry.uuid

The dotnet SDK has been changed some years ago to set DOTNET_CLI_TELEMETRY_OPTOUT=1 in open-source builds (NOT Microsoft builds like dotnet-...-bin from AUR). For PowerShell, such a change was never made, and even open-source builds send the full Telemetry data every single run - unless POWERSHELL_TELEMETRY_OPTOUT is defined. I don't think a package on Linux should default to such behaviour, which is why I made the change.

Hello @ChrisTX, indeed I have a PSTEST_PROFILE_LOAD inside my ~/.profile. I don't know how it got there ... I removed it. EDIT: understood with your patch.

Your latest diff is quite hard to read ^^

Are you sure you are disabling telemetry and not enabling it ? Because even though the env variable is called _telemetryOptoutEnvVar, the variable it is sent to is called CanSendTelemetry... That's not very clear.

Thank you for your work either way :) Regards

@B3l3tte Thank you for your report. I've looked at it, so the test that's failing for you is this one. As you can see the test relies on creating a file ~/.profile before that test is run here. For this reason alone, the test should be disabled. I've updated the package to a new pkgver with that test disabled.

However, can you post the contents of your ~/.profile file? I'm not really sure what can break there unless there's something with that file. It should look like this:

export PSTEST_PROFILE_LOAD='3fdc78bd-8e40-4e2d-a36e-4472b8ad3a18'

with a random UUID. The way your error message sounds almost sounds like New-Guid is broken for you, which is why these warrants looking at despite the test now being disabled in the PKGBUILD.

Edit: I found two more tests with dodgy side effects and removed those in version 4.

Edit 2: I've gone through the source code some more and identified some further side effects that would change test behaviour.

Furthermore, I've changed the default for telemetry to be OFF. If you for whatever reason would want to send telemetry to Microsoft every single time you use powershell, you can override this by defining the environment variable POWERSHELL_TELEMETRY_OPTOUT to 0 - usually, this would need to be set to 1 to disable telemetry.

P.S. This xclip nonsense should be addressed soon upstream. There's a PR for adding support for wayland etc., which has recently been reviewed by the WG.

Hello, thank you for your work on this.

I still have a failing test :

Tests Passed: 12173, Failed: 1, Skipped: 2179, Pending: 203, Inconclusive: 2

I believe it comes from this test:

[-] Doesn't run the login profile when -Login not used 355ms
Expected $null or empty, but got [UUID].
292:             $result | Should -BeNullOrEmpty
at <ScriptBlock>, [$HOME]/.cache/yay/powershell/src/PowerShell/test/powershell/Host/ConsoleHost.Tests.ps1: line 292

Don't you have the same behavior ?

Thank you, Regards

@scardracs you talking about the problem every big -git package maintainer aware of (I guess), alas https://bbs.archlinux.org/viewtopic.php?id=298628

@yataro set a depth=1 for downloading the powershell's git. We don't need the entire history of it and depth=1 makes things much faster.

@yataro Thanks. I've bumped the package to 7.6.2 and worked my way through the various failing tests. Some turned out to be potentially iffy because openssh is needed for PSRemoting and if it isn't available, some tests fail. I ran into this when trying to build in a clean chroot.

I have built the package on different systems both in and outside a chroot and not been able to reproduce a bunch of the tests that are removed. It's possible that upstream fixed the issue in the meanwhile. Thus, I've commented the ones I was not able to reproduce out to test if anyone can reproduce them on 7.6.2 still.