The Comprehensive Kerbal Archive Network (CKAN) Package Manager; v1.18.0 [19 June 2016]

[Olympic1]

Maybe I am drunk, but AutoAsparagus don't show in my CKAN.

It's in there

[hab136]

Maybe I am drunk, but AutoAsparagus don't show in my CKAN.

It's in there

Note that there's a major release pending which greatly expands the type of ships it can handle. See this link if you want to beta test it; release will probably be right after 1.0.5 hits and I verify everything works.

[Guest]

Does CKAN allow me to override the silly "WILL NOT DELETE" safety mechanism via command line or option? I often run HEAD on RSS, RO, and RP-0 long before an update and it'd be nice if I could update to the latest without having to remember to manually delete directories and such.

E: You know what else would be cool is the ability to blacklist a KSP directory from mod installs. For instance, the root ships directory. I hate it when mods install their own "stock" craft to clutter up my interface. With a manual install I can control that.

Edited November 3, 2015 by regex

[steve_v]

CKAN is still buggering up my desktop (KDE) service registry:

kbuildsycoca4(6188)/kdecore (services) KServicePrivate::init: The desktop entry file  "/home/steve/.local/share/applications/ckan-handler.desktop"  has Type= " Application"  instead of "Application" or "Service"
kbuildsycoca4(6188) KBuildServiceFactory::createEntry: Invalid Service :  "/home/steve/.local/share/applications/ckan-handler.desktop"

Deleting this file returns normal operation, but subsequent launches of ckan put it right back.

This is interfering with normal operation of my DE (changes to default application / mimetype registry do not stick).

No notification or "install handler Yes/No" dialog is presented, or ever has been to my knowledge.

I do not see any way do disable this behaviour, in either the CLI or the GUI.

How do I prevent CKAN from lousing up my desktop every time I start it?

For reference, the freedesktop standard. The file ckan generates is incorrect, note the lack of whitespace between 'key=value' pairs in the official spec.

Here's a .desktop file that works:

[Desktop Entry]
Encoding=UTF-8
Value=1.0
Type=Application
Name=Pillars of Eternity
GenericName=Pillars of Eternity
Comment=Pillars of Eternity
Icon=/home/steve/Games/Pillars of Eternity/support/icon.png
Exec="/home/steve/Games/Pillars of Eternity/start.sh" ""
Categories=Game;
Path=/home/steve/Games/Pillars of Eternity

And here's what ckan is generating:

[Desktop Entry]
Version = 1.0
Type = Application
Exec = mono /home/steve/Games/KSP_linux-1004/ckan.exe gui %u
Icon = ckan
StartupNotify = true
Terminal = false
Categories = Utility
MimeType = x-scheme-handler/ckan
Name = CKAN Launcher
Comment = Launch CKAN

As you can see, it's full of 'key = value'. This breaks the KDE mime configuration parser and resets all file associations to defaults.

I'll just leave this here and hope someone spots it, as I got no feedback whatsoever the last time I attempted to call attention to this irritating bug.

Edited November 3, 2015 by steve_v

[politas]

And here's what ckan is generating:

[Desktop Entry]
Version = 1.0
Type = Application
Exec = mono /home/steve/Games/KSP_linux-1004/ckan.exe gui %u
Icon = ckan
StartupNotify = true
Terminal = false
Categories = Utility
MimeType = x-scheme-handler/ckan
Name = CKAN Launcher
Comment = Launch CKAN

As you can see, it's full of 'key = value'. This breaks the KDE mime configuration parser and resets all file associations to defaults.

I'll just leave this here and hope someone spots it, as I got no feedback whatsoever the last time I attempted to call attention to this irritating bug.

CKAN generates a .desktop file? I've never noticed that. Oh, there it is in Applications. And yes, mine is the same as yours, and it doesn't work under Ubuntu's Unity Desktop either. There's no ckan icon, too.

I have a script that I double-click on to launch CKAN. But taking that file and modifying it to this works perfectly:

[Desktop Entry]
Version=1.0
Type=Application
Exec=mono /home/me/Desktop/KSP/ckan/ckan.exe
Icon=/home/me/Desktop/KSP/ckan/ckan.png
StartupNotify=true
Terminal=false
Categories=Game
MimeType=x-scheme-handler/ckan
Name=CKAN
Comment=Comprehensive Kerbal Archive Network

I created ckan.png from the CKAN logo, resized appropriately, and saved that as a new file ckan.desktop. Note that I have taken out the parameters; they aren't required.

- - - Updated - - -

No the KSP folder which was in /home.

What happens if you run these from a command line ?

mono /path/to/ckan/ckan.exe version
mono /path/to/ckan/ckan.exe --help

If they return expected results, try running this:

mono /path/to/ckan/ckan.exe ksp forget

to make CKAN forget what it thinks your current installation has and where it is.

[theersink]

What happens if you run these from a command line ?

mono /path/to/ckan/ckan.exe version
mono /path/to/ckan/ckan.exe --help

If they return expected results, try running this:

mono /path/to/ckan/ckan.exe ksp forget

to make CKAN forget what it thinks your current installation has and where it is.

No dice. Same error.

[Guest]

I'm having issues with mono, which I have installed. I go into terminal, type mono ckan.exe, but it says that the command mono can't be found.

[xspotatoes]

I'm having issues with mono, which I have installed. I go into terminal, type mono ckan.exe, but it says that the command mono can't be found.

Make sure that ckan.exe is in the correct folder. If you're just booting up terminal and you haven't moved ckan from where it normally ends up (probably downloads), you either need to move it to your user directory, or change the directory you're on to the one that ckan is in.

This can be done with the cd command. All you need to do is type in cd downloads (assuming ckan is in downloads) and then mono ckan.exe

[politas]

No dice. Same error.

Ok, so it's nothing to do with anything in your KSP directory. What do you get from

mono --version

CliftonM, can you post the results of this, too, and the exact error message you get when trying to run CKAN?

[Guest]

Does CKAN allow me to override the silly "WILL NOT DELETE" safety mechanism via command line or option? I often run HEAD on RSS, RO, and RP-0 long before an update and it'd be nice if I could update to the latest without having to remember to manually delete directories and such.

Not empty quoting myself.

[steve_v]

CKAN generates a .desktop file? I've never noticed that. Oh, there it is in Applications. And yes, mine is the same as yours, and it doesn't work under Ubuntu's Unity Desktop either. There's no ckan icon, too.

I have a script that I double-click on to launch CKAN. But taking that file and modifying it to this works perfectly.

I too have fixed the file for my own purposes, and set it immutable so ckan can't overwrite it with garbage every startup. It'd be real nice if this could be fixed in ckan though, it should be pretty easy to do.

Whoever added that 'feature' clearly didn't test it very well, it can't have worked on day 1.

- - - Updated - - -

Does CKAN allow me to override the silly "WILL NOT DELETE" safety mechanism via command line or option? I often run HEAD on RSS, RO, and RP-0 long before an update and it'd be nice if I could update to the latest without having to remember to manually delete directories and such.

+1

Some '--force' command-line switch would be real nice.

While on the topic, how about some '--verbose' too? and some history so I can see what (files) have been updated and when? ATM I'm relying on filesystem snapshots to see what ckan changed, but it's not ideal.

[stibbons]

For reference, the freedesktop standard. The file ckan generates is incorrect, note the lack of whitespace between 'key=value' pairs in the official spec.

The spec in that link says

Space before and after the equals sign should be ignored; the = sign is the actual delimiter.

The file CKAN is generating is correct. Your problem seems to be this part of your error log:

The desktop entry file "/home/steve/.local/share/applications/ckan-handler.desktop" has Type= " Application" instead of "Application" or "Service"

which seems to line up with the behaviour described in issue 1498.

[politas]

I too have fixed the file for my own purposes, and set it immutable so ckan can't overwrite it with garbage every startup.

I'm pretty sure it only rewrites those on every CKAN update, not every startup.

[Guest]

Does CKAN allow me to override the silly "WILL NOT DELETE" safety mechanism via command line or option? I often run HEAD on RSS, RO, and RP-0 long before an update and it'd be nice if I could update to the latest without having to remember to manually delete directories and such.

Is this like one of those issues that someone somewhere discussed in depth to death and everyone is just expected to know why it's done the way it's done and that's why no one's even bothered to acknowledge the question?

I'll just ping pjf on IRC or something, clearly it's too much trouble to even throw me a link to an old conversation. Thanks.

[steve_v]

I'm pretty sure it only rewrites those on every CKAN update, not every startup.

Well, it's writing to both ~/.local/share/applications/ckan-handler.desktop & ~/.local/share/applications/mimeapps.list every time I start it - so say both filesystem timestamps and strace.

A cursory look at the code sees a remove & recreate in RegisterURLHandler_Linux but I don't see the conditional for the dialog check in Main... or know C# .

Removing GUIConfig.xml gives me "allow autoupdates"(Y) and "update on startup"(N) confirmation dialogs, but that's all. - ckan-handler.desktop is simply written again without prompting.

The file CKAN is generating is correct.

Given that no other .desktop file on my system has the formatting ckan-handler.desktop has, I'd say it's a good bet that ckan is wrong - which explains why its file doesn't work on KDE, Gnome, or Unity.

It also explains why removing those spaces makes it work, but the irritating bonus is that ckan overwrites the file on startup.

Edited November 7, 2015 by steve_v

[politas]

Is this like one of those issues that someone somewhere discussed in depth to death and everyone is just expected to know why it's done the way it's done and that's why no one's even bothered to acknowledge the question?

I'll just ping pjf on IRC or something, clearly it's too much trouble to even throw me a link to an old conversation. Thanks.

Sorry, I'd have answered, but I really don't know why the decision was made, or where the discussion is. I'm also not entirely sure what you meant about what you were doing with your mods. It may be that the philosophy behind CKAN just isn't suited to what you want to do.

- - - Updated - - -

Well, it's writing to both ~/.local/share/applications/ckan-handler.desktop & ~/.local/share/applications/mimeapps.list every time I start it - so say both filesystem timestamps and strace.

A cursory look at the code sees a remove & recreate in RegisterURLHandler_Linux but I don't see the conditional for the dialog check in Main... or know C# .

Removing GUIConfig.xml gives me "allow autoupdates"(Y) and "update on startup"(N) confirmation dialogs, but that's all. - ckan-handler.desktop is simply written again without prompting.

That's odd. The timestamps on my files match with the last new CKAN version I installed. I've made a new ckan.desktop file, so it won't be overwritten. You could chown ckan-handler.desktop to another userid to prevent ckan over-writing it, I suppose.

Given that no other .desktop file on my system has the formatting ckan-handler.desktop has, I'd say it's a good bet that ckan is wrong - which explains why its file doesn't work on KDE, Gnome, or Unity.

It also explains why removing those spaces makes it work, but the irritating bonus is that ckan overwrites the file on startup.

I think the upshot of that issue is that it will be fixed. It might be more correct to say that both our desktop environments are ignoring that part of the freedesktop spec, but there's a point where you have to stop denying reality, and accept that specs aren't always perfect.

[steve_v]

The timestamps on my files match with the last new CKAN version I installed. I've made a new ckan.desktop file, so it won't be overwritten. You could chown ckan-handler.desktop to another userid to prevent ckan over-writing it, I suppose.

Not sure what's going on here, it's most definitely writing those files at every startup... and overwriting my changes.

Using filesystem permissions to make the files un-writeable by ckan is a short-term solution at best - other things may need to write mimeapps.list, and it'll cause grief later on when I forget what I did.

I think the upshot of that issue is that it will be fixed.

Excellent.

[politas]

Not sure what's going on here, it's most definitely writing those files at every startup... and overwriting my changes.

Using filesystem permissions to make the files un-writeable by ckan is a short-term solution at best - other things may need to write mimeapps.list, and it'll cause grief later on when I forget what I did.

You could create a dummy user and group that the CKAN executable is setuid/setgid for, and then chown the CKAN directory to that group? I think that'd work.

EDIT: Sorry, I meant chown the KSP directory to the group.

Edited November 9, 2015 by politas

[Guest]

Sorry, I'd have answered, but I really don't know why the decision was made, or where the discussion is. I'm also not entirely sure what you meant about what you were doing with your mods. It may be that the philosophy behind CKAN just isn't suited to what you want to do.

CKAN never deletes files within GameData so, if I'm running Realism Overhaul off of Github HEAD (that is, the development version, which I do sometimes for several reasons including making patches), I can't update using CKAN when the latest version is released because files that CKAN doesn't know about may still be in GameData. Therefore, I have to manually delete the RO directory before updating using CKAN. It's a bit annoying.

Another thing that would be nice, especially for those of us who actively test and mod, is to allow removal of a mod without removing the mods that it depends on. For instance, I manually downgraded Real Fuels to 10.6.1 but on refresh CKAN still thinks we're on 10.7.1. I unchecked it from the list and went to remove it and CKAN wanted to remove half of my install. That's a ... kind of mean thing to do to someone who might just want to reinstall an update.

[Sophistry]

Hi, I've just done a clean KSP install and a clean CKAN install. However I get an error message when I open up CKAN: "Error in autoupdate: Unable to connect to the remote server".

It seems to be a bit more than the CKAN autoupdate, as I don't seem to get a modlist either. This has persisted after several reinstalls and restarts of both the program and my computer. Hopefully I'm just doing something daft.

Thanks for any help

EDIT: Fixed by moving CKAN into the KSP directory. Sorry, I didn't find the troubleshooting page until after this post! I wonder why that works.

Edited November 8, 2015 by Sophistry

[politas]

CKAN never deletes files within GameData so, if I'm running Realism Overhaul off of Github HEAD (that is, the development version, which I do sometimes for several reasons including making patches), I can't update using CKAN when the latest version is released because files that CKAN doesn't know about may still be in GameData. Therefore, I have to manually delete the RO directory before updating using CKAN. It's a bit annoying.

Ah, ok, that's what you meant by running them in HEAD. Wouldn't it be easier to have a development KSP install and a gameplay KSP install, and only use CKAN for the gameplay install? I would think you're courting problems in your savegames with advancing and reverting versions. CKAN really isn't aimed at developer use, or for bleeding-edge users. That would seem to be the kind of edge case that should be worked on after the basics of dealing with ordinary users with little computing knowledge is really rock-solid, which it really isn't, yet.

Another thing that would be nice, especially for those of us who actively test and mod, is to allow removal of a mod without removing the mods that it depends on. For instance, I manually downgraded Real Fuels to 10.6.1 but on refresh CKAN still thinks we're on 10.7.1. I unchecked it from the list and went to remove it and CKAN wanted to remove half of my install. That's a ... kind of mean thing to do to someone who might just want to reinstall an update.

You can manually deselect and reselect mods, which will then put them into "selected by user" mode rather than "installed as a dependency" when you update. It'll still remove RO if you remove RealFuels, but all the other mods RO depends on won't get removed.

[inigma]

Is there a place to publish one's ckan export meta file for others to enjoy (as sort of like a well played and tested mod list?)

[kendoka15]

With 1.0.5, half if not more of the modlist isn't showing up. Is this normal behavior? I started using CKAN with 1.0.4 so have never had to deal with a new version.

(If so, it's weird considering many 1.0.4 mods are in fact showing up)

Edited November 10, 2015 by kendoka15

[flyfire29]

I just downloaded CKAN and am getting the error message "Failed to download [file name], could not establish trust relationship for SSL/TSL secure channel". I'm on windows, and not having any trouble going in and manually downloading mods. What's the workaround/solution for this?

Edited November 10, 2015 by flyfire29

[krmcginnis]

With 1.0.5, half if not more of the modlist isn't showing up. Is this normal behavior? I started using CKAN with 1.0.4 so have never had to deal with a new version.

(If so, it's weird considering many 1.0.4 mods are in fact showing up)

You have to click where it says, "Filter" and select "All" instead of "Compatible".