Package Details: ckan 1.22.6-1

Git Clone URL: (read-only)
Package Base: ckan
Description: All you need to find, install, and manage mods for Kerbal Space Program (ksp)
Upstream URL:
Keywords: game kerbal ksp manager mod
Licenses: MIT
Conflicts: ckan-git
Submitter: birdspider
Maintainer: birdspider (spacekookie)
Last Packager: birdspider
Votes: 19
Popularity: 0.360644
First Submitted: 2014-12-30 19:22
Last Updated: 2017-10-29 12:44

Required by (0)

Sources (1)

Latest Comments

birdspider commented on 2017-07-07 10:13


you are now a co-maintainer - feel free to change everything

spacekookie commented on 2017-07-06 16:08


Not that I have to care anymore but I would like to adress some of your comments :P

1) and 2) NO! systemd-binfmt isn't enabled by default, why would it? If you have something quirky on your system then maybe, yea. But don't make assumptions for every user. Especially because enabling it would go *hard* against Arch's core philosophy.

Now, here we're getting into an argument about how a package should behave because...yea, I don't want an AUR package to randomly enable services on my system. But PKGBUILD files are able to communicate to the user. And as such, if your package requires binfmt to be enabled, maybe you should do that. I mean, yea there are comments below to check but that's kinda stupid imho.

3) Addressing your third's not possible to launch CKAN from the CLI if not having binfmt enabled (which I will do when hell freezes over) so the only other choices are a) a wrapper script or b) a .desktop integration file to start from my GUI. Neither is provided by this package. THAT's why I brought up the desktop file, as an alternative way of launching the application. Besides, shouldn't a GUI application provide one anyways just for good measure? It kinda sucks having to start GUIs through the terminal if you ask me.

Also my original point WAS about a wrapper script that removes the need to enable a shitty systemd service and I only later brought up the desktop file as a good measure for "btw, wouldn't it also be neat". But hey...whatever floats your boat.

birdspider commented on 2017-06-04 20:24


1) So you would like a package to mess with your systemd units ? I simply asked if you have it enabled. If I read it correctly core/systemd should have the systemd-binfmt.service enabled by default.

2) see 1) this is the default imho.

3) complain all you want, I just wanted to focus on the issue at hand (not launchable via cli) then you brought up the .desktop file. I inqired if your focus has changed to get it to run via .desktop or if the cli issue was still relevant.

spacekookie commented on 2017-06-04 19:55


1) Why doesn't ckan enable systemd-binfmt if it's required
2) Why would ANYONE in their right mind enable a Linux to execute random windows binary files?
3) I can complain about the application not being launch-able from the terminal if that is the only way the package makes it possible to launch and at the same time want a desktop file

But I guess you're unwilling to change the package. I made my own locally and I guess I'll keep it up to date for myself as well.

If anyone else is interested:

birdspider commented on 2017-06-04 17:20

@spacekookie: it does not fail on my PC; do you have systemd-binfmt.service enabled ? Also as per /opt is for 'Large self-contained packages'. Ckan is neither large nor self-contained (mono).

Why do you care for a .desktop file when your origninal issue was not beeing able to start it from terminal ?

spacekookie commented on 2017-06-04 16:02

@birdspider Well it means that when you run "ckan" from a terminal it fails with "The file '/usr/bin/ckan' is marked as an executable but could not be run by the operating system."

Placing a script at /usr/bin/ckan that calls "mono /opt/ckan/ckan.exe" makes that a lot nicer.

My PKGBUILD also creates a desktop file in /usr/share/applications/

birdspider commented on 2017-06-04 15:51

@spacekookie: what exactly does not work for you, why should I put a wrapper script /usr/bin/ ? What problem would wrapping ckan in an script and putting the binary elsewhere solve ?

spacekookie commented on 2017-06-04 14:50

Your package is pretty broken.

Shouldn't you put a script down as /usr/bin/ckan that runs the ckan binary with mono instead of this? Kinda ugly to just copy the exe into /usr/bin :S

EDIT: I already built a new PKGBUILD for myself. Would you be interested in merging it? And if so, how?

Zekario commented on 2015-11-24 23:34

@birdspider: I tried what you suggested, making sure to enable systemd-binfmt and then trying `$ /usr/bin/mono /usr/bin/ckan`. I now get the same error I do when trying ckan.exe, which I posted at .

birdspider commented on 2015-11-24 13:56

@Zerkario,backleg: it took a while but it seem that to allow linux to exec mono on a file without explicitly saying that it is a mono binary, one has to enable

`systemd-binfmt.service - *Set Up Additional Binary Formats*` like so:

`sudo systemctl start systemd-binfmt`.

My main PC had it enabled by default - a fresh arch install I just testet didn't have it. I do not know if I can tweak the PKGBUILD to do it, probably a bash wrapper with direct `/usr/bin/mono /usr/bin/ckan` call would be the least hassle solution.

All comments