Oni: Update AUR package

[badosu]

https://aur.archlinux.org/packages/oni/ is still in 0.2.6 for quite some time.

You can contact the maintainer to assist, pass the maintenance to me or I can create a new one and maintain it.

[bryphe]

Ah just saw you posted there - thank you @badosu !

Really appreciate the offer to maintain it - creating a new one sounds reasonable. I'm not sure how it got up there in the first place (but it's cool it was added there).

I wonder if there is a way we can automate it, such that we can push it up automatically on a release? It'd be great if it didn't need a manual step.

[terlar]

@badosu I updated to the latest version, I have also added you as co-maintainer and could disown the package (if that is possible) as I am not actively using oni at the moment.

@extr0py It is definitely possible to automate this since this is just updating those files and pushing to the aur git repo, as long as we have a key associated with a maintainer on that package in AUR. Let me know if I can help.

[badosu]

Thanks @terlar! I'll help keeping the package up-to-date, really appreciate.

[bryphe]

Great! Thanks for your help, @terlar and @badosu!

[badosu]

Ideally it would be a good idea to have something like a pkg folder to contain the packaging methods for each system where oni is supported.

I'll see how we can make the PKGBUILD script be used from the main repo and how to automate this.

[bryphe]

That makes sense. I was just looking through the electron-builder documentation (since that is what is used to generate the Linux packages), and I was wondering if they had any faculty for automatically uploading the artifacts.

I was also looking at the release deployment docs in TravisCI: https://docs.travis-ci.com/user/deployment/releases/

Also, it looks like there was a discussion in https://github.com/tectonic-typesetting/tectonic/issues/54 around setting up deployment from TravisCI, which seems doable. Sounds like the biggest challenge is an SSH key is needed, and we may have set up an encryption for that. But it seems possible. Thanks again for your help here!

[badosu]

@extr0py Currently there's no oni icon or desktop entry on Arch, I'll take a look on how to add that later on.

[bryphe]

Ah interesting, bummer... thank you for catching that! I really need to set up an Arch machine at some point so I can test it there and it isn't a second-class citizen...

[badosu]

@extr0py I made a desktop file for oni and also scripts to download and update the icons for arch packaging.

You can find these at:

• https://aur.archlinux.org/cgit/aur.git/tree/oni.desktop?h=oni
• https://aur.archlinux.org/cgit/aur.git/tree/update-icons.sh?h=oni
• https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=oni

One odd thing I found when I was writing a custom Desktop Action, and setting Oni as a file opener application for certain Mime Types is that oni is not respecting oni %f and opening %f. Is this just not implemented or a bug?

[badosu]

@terlar Is there a reason for using the oni.sh wrapper?

[bryphe]

Excellent, thanks for your help @badosu getting Oni set up on arch! Really appreciate it.

One odd thing I found when I was writing a custom Desktop Action, and setting Oni as a file opener application for certain Mime Types is that oni is not respecting oni %f and opening %f. Is this just not implemented or a bug?

There was special work done on both Windows and OSX to handle this: https://github.com/extr0py/oni/blob/3dff7aa524c1f0595fb0609b90a716faf8e64f6b/main/src/main.ts#L159

function loadFileFromArguments(platform, args, workingDirectory) {
    const windowsOpenWith = platform === "win32" &&
                            args[0].split("\\").pop() === "Oni.exe"

    const macOpenWith = platform === "darwin" &&
                            args[0].indexOf("Oni.app") >= 0

    if (windowsOpenWith || macOpenWith) {
        createWindow(args.slice(1), workingDirectory)
    } else {
        createWindow(args.slice(2), workingDirectory)
    }
}

Potentially we need to handle this in Linux too, as the number of arguments expected varies depending on how it is run.

Unfortunately I still don't have an Arch machine available... But one thing that can help troubleshoot is to run oni %f, and then open the developer tools, and run this line of code in the console:

require("electron").remote.process.argv:

Here's the output on my Windows dev machine (without opening a file):

That will let us do two things - validate that the %f parameter is actually making it to Oni (ruling out an issue with the oni.sh file), as well as guide any changes that need to be made to that loadFileFromArgument method above.

Thanks again for all your help, @badosu !

[badosu]

The Desktop file actually should be usable for any linux machine, not only Arch, so if you want to distribute Oni on Linux, you'll want to create one. I think electron-builder is able to create one automatically for you.

See the screenshot for the inspected console, note the error on the logs.

If you want to setup an Arch-compatible machine I recommend Manjaro as it`s really straightforward to install as opposed to having to follow through the Arch tutorial.

[badosu]

Another possibility is uploading the desktop file to the repository and using it as a source for all the different packaging systems.

[terlar]

@badosu the reasoning behind the oni.sh is a pattern I saw from some other packages (e.g. https://aur.archlinux.org/packages/franz-bin), it is because the binary is in /opt/oni/oni and that is not in users PATH. Another alternative would be to symlink it instead.

[bryphe]

If you want to setup an Arch-compatible machine I recommend Manjaro as it`s really straightforward to install as opposed to having to follow through the Arch tutorial.

Cool, this helps a lot! I started doing some research and the arch tutorial I looked at basically had you set it up from scratch. Didn't know about Manjaro, I'll check that out.

Another possibility is uploading the desktop file to the repository and using it as a source for all the different packaging systems.

@badosu, that sounds reasonable! Could we just bring it into the repo as-is, perhaps under the build/linux folder?

[bryphe]

@badosu - thanks for the tip about Manjaro! I finally got around to installing it today... it was _much_ simpler than the normal Arch install...