Issue in the documentation regarding distribution

[ShalokShalom]

You state in the documentation, that dpkg ... .deb is the way to install fvim on Linux. This will not work on over 60 percent of all cases, since there are other distributions out there, next to .deb based ones.

[yatli]

hi @ShalokShalom !

You can always unarchive .deb packages with ar -- the package structure is pretty simple -- some stuff go into /usr/share, and a startup script goes into /usr/bin.

suggestions/PR on other package formats are also welcomed.

[yatli]

@jjohnson338 wink wink (

[jjohnson338]

I'm currently working on a PKGBUILD for the Arch Linux user repository (on nights when I have the time). Once I've got that down, I can work on flushing out the install instructions :)

[yatli]

great!

looping in @thautwarm

[jjohnson338]

Here is the in-progress pkgbuild if it's any help in the meantime. Not sure if I need to build before I publish for dotnet core apps to grab the deps? Because the published only version doesn't execute currently.

Also plan to copy the in-repo .desktop file to /usr/share/applications

[jjohnson338]

🤦‍♂️ Looks like this file (that I missed) is a pretty good step by step of how to package the application. I'll see if I can finish out the PKGBUILD and get it in the AUR tonight.

[yatli]

ha! just about to post this, and you've found it. just install fpm and there're a lot of supported formats

[ShalokShalom]

I could port that PKGBUILD to KaOS, thanks a lot.

[jjohnson338]

Not sure if this is the proper place to post this, but I've run into an issue with the PKGBUILD I've been working on Link Here

The compiled application runs from the directory I've published to, but once I copy it out to the package directory, it no longer executes complaining of missing references:

The only real difference I can see is that the "publish" directory has a FVim.runtimeconfig.dev.json file that is missing once copied over?

  "runtimeOptions": {
    "additionalProbingPaths": [
      "/home/jared/.dotnet/store/|arch|/|tfm|",
      "/home/jared/.nuget/packages"
    ]
  }
}

Please let me know if there is something obvious that I'm doing wrong in my attempt to package the application for Arch Linux

[yatli]

@jjohnson338 I don't really know how PKGBUILD works but I took a look at the build script, the difference to pack.sh I see:

1. --self-contained is paired with true, which is missing in pack.sh (just checked the doc, this is supported)
2. -o used to designate the output directory
3. pack.sh copies the publish directory, and on the other hand, PKGBUILD copies the -o designated directory

I just tried this on Windows:

dotnet publish -f netcoreapp3.0 -r win10-x64 -c Release -o test_pub --self-contained
cd test_pub
$a = Get-ChildItem -Recurse .
$b = Get-ChildItem -Recurse ..\bin\Release\netcoreapp3.0\win10-x64
Compare-Object $a $b

... and surprisingly the -o directory is not very self contained:

InputObject                                       SideIndicator
-----------                                       -------------
FVim.runtimeconfig.dev.json                       =>
Microsoft.CSharp.dll                              =>
Microsoft.VisualBasic.Core.dll                    =>
mscorlib.dll                                      =>
netstandard.dll                                   =>
System.AppContext.dll                             =>
System.Buffers.dll                                =>
System.ComponentModel.DataAnnotations.dll         =>
System.Configuration.dll                          =>
System.Core.dll                                   =>
System.Data.DataSetExtensions.dll                 =>
System.Data.dll                                   =>
System.Diagnostics.Contracts.dll                  =>
System.Diagnostics.Debug.dll                      =>
System.Diagnostics.TextWriterTraceListener.dll    =>
System.Diagnostics.Tracing.dll                    =>
System.dll                                        =>
System.Drawing.dll                                =>
System.Dynamic.Runtime.dll                        =>
System.Globalization.Calendars.dll                =>
System.Globalization.dll                          =>
System.Globalization.Extensions.dll               =>
System.IO.Compression.FileSystem.dll              =>
System.IO.dll                                     =>
System.IO.FileSystem.AccessControl.dll            =>
System.IO.FileSystem.Primitives.dll               =>
System.IO.IsolatedStorage.dll                     =>
System.IO.Pipes.AccessControl.dll                 =>
System.IO.UnmanagedMemoryStream.dll               =>
System.Memory.dll                                 =>
System.Net.dll                                    =>
System.Net.HttpListener.dll                       =>
System.Net.Ping.dll                               =>
System.Net.WebProxy.dll                           =>
System.Net.WebSockets.Client.dll                  =>
System.Net.WebSockets.dll                         =>
System.Numerics.dll                               =>
System.Numerics.Vectors.dll                       =>
System.Private.CoreLib.dll                        =>
System.Reflection.DispatchProxy.dll               =>
System.Reflection.dll                             =>
System.Reflection.Emit.dll                        =>
System.Reflection.Emit.ILGeneration.dll           =>
System.Reflection.Emit.Lightweight.dll            =>
System.Reflection.Extensions.dll                  =>
System.Reflection.Primitives.dll                  =>
System.Resources.Reader.dll                       =>
System.Resources.ResourceManager.dll              =>
System.Resources.Writer.dll                       =>
System.Runtime.CompilerServices.VisualC.dll       =>
System.Runtime.Handles.dll                        =>
System.Runtime.InteropServices.WindowsRuntime.dll =>
System.Runtime.Intrinsics.dll                     =>
System.Runtime.Loader.dll                         =>
System.Runtime.Serialization.dll                  =>
System.Runtime.Serialization.Json.dll             =>
System.Runtime.Serialization.Xml.dll              =>
System.Runtime.WindowsRuntime.dll                 =>
System.Runtime.WindowsRuntime.UI.Xaml.dll         =>
System.Security.Cryptography.OpenSsl.dll          =>
System.Security.dll                               =>
System.Security.SecureString.dll                  =>
System.ServiceModel.Web.dll                       =>
System.ServiceProcess.dll                         =>
System.Text.Encoding.CodePages.dll                =>
System.Text.Encoding.dll                          =>
System.Text.Encoding.Extensions.dll               =>
System.Text.Encodings.Web.dll                     =>
System.Text.Json.dll                              =>
System.Threading.Channels.dll                     =>
System.Threading.Overlapped.dll                   =>
System.Threading.Tasks.Dataflow.dll               =>
System.Threading.Tasks.dll                        =>
System.Threading.Tasks.Extensions.dll             =>
System.Threading.Thread.dll                       =>
System.Threading.ThreadPool.dll                   =>
System.Threading.Timer.dll                        =>
System.Transactions.dll                           =>
System.Transactions.Local.dll                     =>
System.ValueTuple.dll                             =>
System.Web.dll                                    =>
System.Web.HttpUtility.dll                        =>
System.Windows.dll                                =>
System.Xml.dll                                    =>
System.Xml.Linq.dll                               =>
System.Xml.ReaderWriter.dll                       =>
System.Xml.Serialization.dll                      =>
System.Xml.XDocument.dll                          =>
System.Xml.XmlDocument.dll                        =>
System.Xml.XmlSerializer.dll                      =>
System.Xml.XPath.dll                              =>
System.Xml.XPath.XDocument.dll                    =>
WindowsBase.dll                                   =>

... and I cannot run FVim.exe from test_pub!

so obviously that -o is wonky. I recommend sticking with bin/Release/netcoreapp3.0/linux-x64

[yatli]

I guess I'm bitten by dotnet in so many ways that I am trained to subconsciously avoid any unnecessary flags :D :D :D

[jjohnson338]

Thanks for looking into it! I figured it out. Creating a package from a PKGBUILD file (makepkg) strips out static libs by default unless the following configuration is included:

options=('staticlibs')

fvim is available from the AUR now! https://aur.archlinux.org/packages/fvim/

[jjohnson338]

@yatli I've made a branch off of my fork rpm_build that should package an rpm in addition to the existing deb package as part of the build process. I've tested this on my local (arch linux) machine, it works there. I tried to create a Ubuntu 16.04 WSL instance on my desktop, but I can't seem to get it to package in that env, but maybe it would still package properly via the Azure pipeline process you use?

If you get a chance, could you test it on your end and let me know if it's safe to open a pull request?

[yatli]

excellent! you can send the PR over and I can then test the branch with the build pipeline :) you may also update azure_pipeline.yml so that the rpm package is also uploaded to the file drop.

[jjohnson338]

@yatli I've made the pull request. I did ending up modding the azure-pipelines.yaml file, but only to add a build dependency (rpm). The existing .deb file isn't referenced in that file directly, only drop-linux artifact. So if I'm understanding it correctly, so long as I dump the resulting .rpm in the same publish dir (which the changes in that pull request should do), it should be picked up as well?

[yatli]

yeah you're right. I forgot most of the details setting up these CIs. :) the rpm package is collected for the PR:

here's the link to the build: https://v-yadli.visualstudio.com/fvim/_build/results?buildId=205

[jjohnson338]

Fantastic! Looks like it worked!

[jjohnson338]

@yatli I'm going to spin up a Fedora VM and try to test the resulting package.

[jjohnson338]

@yatli I spun up a Fedora 29 VM and following installing neovim, I downloaded, installed, and tested the rpm artifact. It worked without issue :)

[yatli]

let's merge this one then. thanks a lot!

[ShalokShalom]

The RPM is not yet in the documentation. I will soon have time to port the PKGBUILD to our distribution, I will post that one here then as well. Thanks a lot for all your support!

[yatli]

@ShalokShalom cool. The rpm package will be integrated to the release system in the next release, and I’ll update the docs altogether.

I’ll need advise from you guys about the installation commands, pacman, yum, dnf etc.

[jjohnson338]

@ShalokShalom When you do port the PKGBUILD, please pull the version from the AUR, it's been updated several times since I posted my WIP here. Direct link here

[yatli]

@jjohnson338 any chance the PKGBUILD file could be integrated in this repo in some way? I've been bugged by several similar problems including brew, chocolatey etc. -- the lifted build scripts always point to a fixed version, some are fixed with checksums (AUR doesn't do that, it appears).

looping in @TylerLeonhardt

[jjohnson338]

@yatli I could certainly check the PKGBUILD into the fvim repo, but the actual interface with the AUR is a standalone git repo containing only the PKGBUILD script. My process is (when the version number is bumped in the app), I update the PKGBUILD in my AUR git repo and push a commit. So I'm trying to think of a workflow that makes sense here. Potentially you could reference the AUR git repo as a submodule? https://git-scm.com/book/en/v2/Git-Tools-Submodules

Also, in many cases people develop 'git' versions of a PKGBUILD for an application: fvim-git for example. Those generally pull the latest from source control, generate a version number from the source, build, and package that. Here is one such example.

In any case, please let me know how you would like me to proceed with integrating. Also, here is the git repo I use for my AUR interaction: https://aur.archlinux.org/fvim.git

[jjohnson338]

@yatli The latest release doesn't include the .rpm package. I checked the logs from the Azure pipeline and it looks like it silently failed uploading the rpm?

2019-09-09T04:42:20.0716947Z ##[section]Async Command Start: Upload Artifact
2019-09-09T04:42:20.0717400Z Uploading 2 files
2019-09-09T04:42:25.0696404Z Uploading 'drop-linux/fvim-0.2_96_g269872a-1.x86_64.rpm' (14%)
2019-09-09T04:42:25.0697131Z Uploading 'drop-linux/fvim-0.2_96_g269872a-1.x86_64.rpm' (28%)
2019-09-09T04:42:25.0697379Z Uploading 'drop-linux/fvim-0.2_96_g269872a-1.x86_64.rpm' (42%)
2019-09-09T04:42:25.0697517Z Uploading 'drop-linux/fvim-0.2_96_g269872a-1.x86_64.rpm' (57%)
2019-09-09T04:42:25.0697759Z Uploading 'drop-linux/fvim-0.2_96_g269872a-1.x86_64.rpm' (71%)
2019-09-09T04:42:25.0697965Z Uploading 'drop-linux/fvim-0.2_96_g269872a-1.x86_64.rpm' (85%)
2019-09-09T04:42:25.0698259Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (14%)
2019-09-09T04:42:25.0698397Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (28%)
2019-09-09T04:42:25.0698526Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (42%)
2019-09-09T04:42:25.0698703Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (57%)
2019-09-09T04:42:25.0698891Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (71%)
2019-09-09T04:42:25.0699029Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (85%)
2019-09-09T04:42:25.0699177Z Uploading 'drop-linux/fvim_0.2-96-g269872a_amd64.deb' (100%)
2019-09-09T04:42:26.0589210Z File upload succeed.

Note the rpm never gets to 100%. Or maybe I'm reading this wrong and other CI configuration exists outside of the azure_pipelines file?

[yatli]

there's an extra step in the release pipeline (which cannot be configured via a config file, unlike the build pipeline).

modded the release and it should be working now.

[yatli]

README updated. I think we can close this issue now -- the package format coverage is much improved.

We can start another thread to discuss the more up-to-date way of packaging. Thanks everyone!