Mastodawn

Felix Palmen 📯Mar 27, 2024

Goal: Get some #letsencrypt certificate obtained with #uacme deployed on some #Windows box

Step 1: Ok, this probably works best with #Powershell (which I don't really like ...)

Step 2: There's no #FreeBSD port ... but hey, there's now a FreeBSD port of #dotnet, let's try to "just" build Powershell using that.

Step 3: Hell why does it fail to build. Oh, System.Security.Cryptography.Native doesn't play well with #LibreSSL

Patch and retry, I guess I'll take some sleep now first. Bah!

(there's some irony in running into OpenSSL/LibreSSL issues when trying to deploy TLS certificates ...)

Show thread

Felix Palmen 📯Mar 28, 2024

I guess that's progress ... some #PowerShell on #FreeBSD at least starting up. Creating a #port out of this will be a lot of work 😞 had to patch quite some code, e.g. completely disable the "login shell" functionality, the implementations only work on either #Linux or #MacOS....

And the whole build system fails completely if not built from within a #git working copy ... WTF? This will be another challenge for porting.

Ah, this messy version is probably a result of the mess in the upstream repo, a tag v7.4.1 exists, but refers to a commit that is gone.

Oh what did I expect ... 😂

Show thread

Felix Palmen 📯Mar 29, 2024

This will be though.

Well, I can certainly build #PowerShell for #FreeBSD now. I might be able to just "fake" a #git working copy for its stupid build system. This still doesn't fully solve the version issue, it insists on appending the git hash -> TODO.

The "login shell" feature can be added, an exercise left for later, the code will look pretty similar to the existing MacOS-X implementation. Maybe upstream would even accept it 😎

For a #port, it should probably be "published" as "#ReadyToRun" (I hope this has no negative impact), otherwise lang/dotnet would become a hard run dependency ... This works now as well, but requires changes in lang/dotnet ... requires some platform-specific #NuGet packages that don't exist on MS servers for FreeBSD. They are created during build of dotnet itself, but not installed anywhere by default ... I'll suggest an "on by default" port option to bundle these with lang/dotnet.

[…]

Show thread

Felix Palmen 📯Mar 29, 2024

The biggest issue will probably be to find some at least somewhat sane way to download the required #NuGet packages during #port fetch phase, so they can be used "offline" during build later. Of course if ever possible with correct checksumming in distinfo.

This is always the same annoying crap with all these languages and frameworks inventing their own package management. Sucks.

For #NuGet, I tought the commandline client could maybe help with the task. Well if anyone can tell me how to even build that thing ... I guess I'll give up and look for other ideas. Should be possible to somehow automate the process to get the correct uris for package downloads? And then maybe patch the build files of #PowerShell to exclusively use a local directory as the "package source" ... we will see.

Show thread

Joel Bennett

@zirias you should (be able to) do all your #package tasks with the #dotnet CLI instead, I think.

#nuget itself is still a "Framework" app which requires #Mono...

My current practice for PowerShell projects that need nuget packages is something like...
1. Make a dependencies.csproj file with nothing in it (specify your target platforms)
2. `dotnet add` your dependencies to that.
3. `dotnet publish`
4. delete the dependencies.* files and the rest are your actual dependencies...

Show thread

Felix Palmen 📯Mar 30, 2024

@jaykul Well that certainly explains why it tries to restore framework packages even when you force it to target "net8.0" and once you patch that, you get compiler errors about string handling and locales 🙄

Unfortunately, I don't even know yet exactly what I will need, it will be something that neither nuget nor dotnet is designed for. This is about #packaging software (here #PowerShell for #FreeBSD), and at least FreeBSD's ports (quite some other package build systems as well) strictly separate the "fetch" phase from the "build" phase (with some checksumming in-between and no network access allowed any more to prevent tampering). This is always a major PITA with any language/framework "package managers" like nuget.

A separate "dotnet restore" looks like a start, but requires the source to be already extracted, and even then, integrating with checksumming won't be easy 😞