Arch Linux User Repository

@weltio xdg-open is needed by PowerShell, see my comment here in the PKGBUILD. It's hardcoded in .NET, see here. The tests break because the invoke functionality of PowerShell breaks. That's why there's a hard dependency on xdg-utils - so I'm not quite sure how you managed to not have xdg-open? For me it works on headless systems both, in a chroot and bare metal builds.

As for the --force, I'm aware, that's because you didn't clean the build directory. I'll fix that with the next release though (as my health permits).

Update with 7.6.6-1 this has been addressed.

@B3l3tte xdg-utils entire logic is based on which desktop environment you have. Specifically, for Terminals, it queries here via kreadconfig6 what your terminal is. For me on KDE as well:

$ kreadconfig6 --file kdeglobals --group General --key TerminalApplication --default console
/usr/bin/ghostty --gtk-single-instance=true

What you need to do is go System Settings -> Default Applications and set which terminal you want it to use (and have installed). Then the kreadconfig6 command will return the right setting. Alternatively, build in a chroot, but you should fix this, as there's more apps relying on this. See also the upstream requirements for each DE.

As for qtpaths, yeah you will need qt5-tools installed. It's been removed upstream, see here, but in the current release 1.2.1, it's still there.

I can't really do anything about all of this, since it's a hard dependency of PowerShell / .NET. You will need a working xdg-utils.

I could only build with

--- a/PKGBUILD 
+++ b/PKGBUILD 
@@ prepare() 
   export NUGET_PACKAGES="$PWD/nuget" 
-  dotnet new tool-manifest 
+  dotnet new tool-manifest --force 
   dotnet tool install dotnet-outdated-tool 

@@ check() — before the pwsh -command block 
-    $build_mods = New-Item -Type Directory -Name build-modules 
+    $build_mods = New-Item -Type Directory -Name build-modules -Force 

@@ check() — after the Telemetry.Tests.ps1 removal 
   # We disable telemetry by default, which the telemetry tests don't expect. 
   rm engine/Basic/Telemetry.Tests.ps1 
+ 
+  # These tests open files/folders via a desktop handler (xdg-open), which 
+  # doesn't exist in the headless build environment. 
+  rm Language/Scripting/NativeExecution/NativeCommandProcessor.Tests.ps1 
+  rm Modules/Microsoft.PowerShell.Utility/Invoke-Item.Tests.ps1 

Hello ChrisTX,

I had the following error since 7.6.3-x:

In Function1
In Get-TestCmdlet (begin)
In Get-TestCmdlet (process)
In Get-TestCmdlet (end)
    PID TTY          TIME CMD
   7013 pts/2    00:00:00 bash
   7181 pts/2    00:00:00 yay
  11702 pts/2    00:00:22 dotnet
  11703 pts/2    00:00:22 dotnet
  11704 pts/2    00:00:21 dotnet
  11705 pts/2    00:00:21 dotnet
  11706 pts/2    00:00:14 dotnet
  11707 pts/2    00:00:10 dotnet
  11708 pts/2    00:00:11 dotnet
  11709 pts/2    00:00:05 dotnet
  11710 pts/2    00:00:05 dotnet
  11777 pts/2    00:00:04 dotnet
  11781 pts/2    00:00:04 dotnet
  17585 pts/2    00:00:00 makepkg
  18568 pts/2    00:01:41 VBCSCompiler
  21974 pts/2    00:01:48 pwsh
  27281 pts/2    00:00:00 pwsh
  27294 pts/2    00:00:00 pwsh
  27336 pts/2    00:00:00 ps
Set-Content: 
Line |
  12 |   $null = Set-Content -Path /tmp/3da8755c-6faa-47ae-b624-12653dd2c83c/ …
     |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Could not find a part of the path '/tmp/3da8755c-6faa-47ae-b624-12653dd2c83c/out'.
/usr/bin/xdg-mime: line 885: qtpaths: command not found
kf.kio.core: Terminal "konsole" not found, service "nativeCommandProcessor"
kf.kio.gui: "/bin/sh" "Terminal konsole not found while trying to run /home/$USER/.local/share/applications/nativeCommandProcessor.desktop"
Terminal konsole not found while trying to run /home/$USER/.local/share/applications/nativeCommandProcessor.desktop
    [-] Should open text file without error 10.1s
      Expected $true, but got $false.
      301:             Wait-FileToBePresent -File "$HOME/nativeCommandProcessor.Success" -TimeoutInSeconds 10 -IntervalInMilliseconds 100 | Should -BeTrue
      at <ScriptBlock>, /home/$USER/.cache/yay/powershell/src/PowerShell/test/powershell/Language/Scripting/NativeExecution/NativeCommandProcessor.Tests.ps1: line 301
/usr/bin/xdg-mime: line 885: qtpaths: command not found

Installing konsole seems to solve the issue, which is weird. Just to let you know...

I've pushed at least the update to 7.6.5 now.

To be frank, I've been fighting a really bad pain condition since early July. It's not a permanent affair, and is starting to heal off now. I had hoped it would go away much more quickly, but unfortunately that didn't happen.

I hope I can get back to working on the improvements I had outlined in June in the coming days/weeks.

@rubin55 Can you outline what test it is and how it breaks for you? I assume you're referring to this test in Start-Process.Tests.ps1? That looks like it should error, and it does clear the USERNAME variable due to #4671.

At any rate, I don't think unsetting USERNAME there is a good idea. This could break this test for example. Overall, #4671 demonstrates why it's bad.

I think the best course of action would be patching the test instead, or maybe removing Start-Process.Tests.ps1 entirely. But ideally I'd like to make an upstream bugreport first. The line is certainly not correct due to #4671, but I need to understand how it breaks before I can do so. I've been unable on several machines using regular builds and clean chroot builds to reproduce this. Does it work for you in chroot?

PowerShell version 7.6.5 was released August 14th. Any plans to update the PKGBUILD? If not, do you want to pass the baton to someone else?

Hey came across your package, much greatness. I took the liberty to upgrade to 7.6.5, and encountered a test failure due to USERNAME being set. Here's the PKGBUILD diff:

diff --git a/PKGBUILD b/PKGBUILD
index 382ae5d..873a498 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -26,8 +26,8 @@
 #######################################################################

 pkgname=powershell
-pkgver=7.6.3
-pkgrel=7
+pkgver=7.6.5
+pkgrel=1
 pkgdesc="A cross-platform automation and configuration tool/framework"
 arch=('x86_64')
 url='https://microsoft.com/PowerShell'
@@ -71,8 +71,8 @@ checkdepends=(
 install=powershell.install

 source=("git+https://github.com/PowerShell/PowerShell.git#tag=v$pkgver")
-sha512sums=('2a185b1388744ff2ae36d87a56734532381fa0fcfa71b7c973ac0efbafe0347a9ae43f4b7b76fde69484d7ae35e208500923aed8904f5e8824073b2f621baec3')
-b2sums=('9846ac2506e74038ad74d1f79e9de8eadd1f0d54a5855109e3d38fb4e960c9f0f7d004c06e893ec8aac9f4ffa3cd86fa933583acaf61613e722d365a1a00316c')
+sha512sums=('015912c995c20158ac16557a4b9e8a7acfac26f8a256076f108e1dec8f5226eef0a642dd97b7f5d31cb398aaab5f83e58015e81bfeb23743878ab8858514573a')
+b2sums=('e74fbead4c4af08182aa808f166ce9edffca064be15676dad88af7d99714fc8cbfb359d38f44073cb442e10dae102475563ad753a1adbd0939bb11105ae8487d')

 prepare() {
   cd PowerShell
@@ -383,6 +383,9 @@ check() {
   export LANG=en_US.UTF-8
   export LC_ALL=en_US.UTF-8

+  # USERNAME must be unset, -UseNewEnvironment clears it on Unix
+  unset USERNAME
+
   # shellcheck disable=SC2016
   pwsh -noprofile -command '
     $build_mods = New-Item -Type Directory -Name build-modules

I'll push the update to 7.6.4 with further fixes in the coming days. Unfortunately, I had both a bit of a personal issue as well as my PC breaking down. Sorry for the lack of updates thus.

@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