SUMMARY Projects plugin does not list any files when opening a project that is using a Git repository. Projects-view shows <untracked>. Adding .kateproject to create project manually does not help. STEPS TO REPRODUCE 1. Install kate from Ubuntu default repository or by flatpack 2. Enable Projects plugin and check that Autoload is enabled for Git 3. Open any file from a project that uses Git repository OBSERVED RESULT Projects-view shows <untracked> EXPECTED RESULT Git repository files are listed in the Projects-view SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Ubuntu 20.04.1 LTS KDE Plasma Version: KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION
I have no big knowledge about flatpack. Is perhaps the issue that Kate isn't able to start the "git" command from inside the flatpack? Albert, have you some knowledge about this? I just search a bit around who has touched the flatpack stuff.
*** This bug has been marked as a duplicate of bug 433738 ***
Upsa, I mixed flatpack up with snap, didn't want to duplicate this bug...
If being able to run git is needed for this that is defenitely the case. I'll see how hard is to package git in the kate flatpak
Hmm, can't we have just access to the system? Git will not be enough, for example for the LSP stuff, we need a lot more tools. Same for "External Commands". For LSP that would be all we have here: https://invent.kde.org/utilities/kate/-/blob/master/addons/lspclient/settings.json I actually use Kate now always with at least the clangd or ocamllsp stuff installed. And I don't think we want to bundle X programming languages in the Kate flatpack.
I second that: Without Kate being able to access arbitrary tools, Kate's functionality will be very limited, and we'll get bug reports about it. Packaging git is not the correct approach. Can't access to the system simply be granted somehow?
(In reply to Dominik Haumann from comment #6) > I second that: Without Kate being able to access arbitrary tools, Kate's > functionality will be very limited, and we'll get bug reports about it. > > Packaging git is not the correct approach. Can't access to the system simply > be granted somehow? No, you can't get access to the system binaries. We can remove kate from flatpak if you want, but yes, packging git and all the dependencies kate needs is the correct approach, kate needs git, so kate has to include git (or the base-kde-runtime it uses would need to include git, but it doesn't because it doesn't make sense). how can otherwise kate know that git is available?
(In reply to Albert Astals Cid from comment #7) > (In reply to Dominik Haumann from comment #6) > > I second that: Without Kate being able to access arbitrary tools, Kate's > > functionality will be very limited, and we'll get bug reports about it. > > > > Packaging git is not the correct approach. Can't access to the system simply > > be granted somehow? > > No, you can't get access to the system binaries. > > We can remove kate from flatpak if you want, but yes, packging git and all > the dependencies kate needs is the correct approach, kate needs git, so kate > has to include git (or the base-kde-runtime it uses would need to include > git, but it doesn't because it doesn't make sense). how can otherwise kate > know that git is available? Then I think removing is the only option. For the version control: If one has local git stuff, we assume you have git, same if you have Mercurial repositories, naturally you will have Mercurial installed. It would be strange that installing Kate requires that all these things are installed, even if you don't use them. Naturally, we could improve the runtime error messages, thought for Flatpak that won't help, if there is no way to ever access that stuff even if the user installs it. Same for the LSP stuff: naturally, we don't want that Kate requires that you have OCaml/clang/Perl/Go/Rust/.... installed. Nor does it help to bundle all this, given you normally have some own versions required for your projects, therefore we must rely on the fact what is in the path. I think a KWrite Flatpak is fine, but for stuff like Kate it doesn't work out. (guess same for KDevelop/...) Actually, if it can't access the outside, stuff like the internal terminal and the external tools are even more affects, as we don't know what people want to use/configure there.
hmmm, actually i think i have the solution we can change the kate runtime from org.kde.Platform to org.kde.Sdk and then it will have access to all the devel tools that the Sdk ships that i guess is what you want.
Hmm, what does the SDK provide? I somehow doubt that it has the go language server or stuff like the haskell one, not even speaking about the ocaml one I use often. If there is no way to just get the stuff the user has in the environment, I don't think that is a solution, but perhaps I misunderstand that. As a user I would expect to have access to all my development stuff I have installed. I can see that it might be good enough if we ship some "KDE IDE" if all the stuff there is enough to build a typical KDE/Qt application. But with LSP and Co. we aim to be usable for a lot of different workflows.
> If there is no way to just get the stuff the user has in the environment, I don't think that is a solution, but perhaps I misunderstand that. Well, the user has access to anything he has in his /home, it's just that system stuff that he doesn't have accesible, because well, flatpak apps are supposed to be self contained, same as in windows store, and i guess you still want kate to be available there? I mean think in a regular distro world, you expect kate to depend on git or on other packages that it needs (or the user needs to be able to set up to use stuff from /home), well in flatpak world there's no dependencies, so it need to be in the package (or the user needs to be able to set up to use stuff from /home) I don't really see the difference.
(In reply to Albert Astals Cid from comment #11) > > If there is no way to just get the stuff the user has in the environment, I don't think that is a solution, but perhaps I misunderstand that. > > Well, the user has access to anything he has in his /home, it's just that > system stuff that he doesn't have accesible, because well, flatpak apps are > supposed to be self contained, same as in windows store, and i guess you > still want kate to be available there? No, the Windows Store has no such limitations. If you have git in your path, it will work. There is no sandboxing that hinders any such stuff. Same for any other kind of external process. That is more or less like how an AppImage works. All is packed together but no real sandboxing around. > > I mean think in a regular distro world, you expect kate to depend on git or > on other packages that it needs (or the user needs to be able to set up to > use stuff from /home), well in flatpak world there's no dependencies, so it > need to be in the package (or the user needs to be able to set up to use > stuff from /home) > > I don't really see the difference. How should stuff like LSP work with Kate then in the real world? We don't want to depend on all LSP servers we support, users can even configure their own ones. Same for external commands. How shall we know if the user wants to call rustfmt? And why should that be forbidden? The regular user has a personal computer where he can install stuff via package manager and e.g. in our company, all stuff we need for our development is globally installed, Kate will just pick up the right OCaml LSP server. I can clearly see the point of sandboxed stuff. But I think it just makes no sense for Kate. Btw., same for KDevelop, I can't really see how I shall work with it, if it uses just the bundled CMake/gcc/clang that is totally different to what my actual project I work on with it requires. But for KDevelop they KDevelop people must say what makes sense, for Kate I don't see really how it makes sense in practice.
As far as I understand, there's the possibility of providing those as extensions. Depending on the Sdk as the runtime rather than just the Platform will give us access to a bigger set of tools. Regarding executing, there is also the possibility of requesting the execution of processes outside. This could be explored if you want to support tools like that. By-passing the sandboxing isn't ideal though.
(In reply to Aleix Pol from comment #13) > As far as I understand, there's the possibility of providing those as > extensions. Depending on the Sdk as the runtime rather than just the > Platform will give us access to a bigger set of tools. That is ok for many things but will not help Kate. E.g. the build plugin wants to run exactly the cmake/compiler the user has in its path, not the flatpak sdk compiler, that will just break your local compiles. Same for LSP, we need access to the user environment, not some other variants. The integrated terminal and external tools only make sense with proper shell access to the user & system environment, too. > > Regarding executing, there is also the possibility of requesting the > execution of processes outside. This could be explored if you want to > support tools like that. By-passing the sandboxing isn't ideal though. If somebody does that, perfect, but at the moment I think the only reasonable solution is to only package e.g. kwrite but not kate for flatpak. If somebody provides maintainable patches to get this all working, one can still package it again.
I'm with Christoph here. If access to system tools is not there, then the plugins External Tools, LSP Client, Terminal, Build Plugin, and possibly some others don't work. Given this, I suggest we remove the download links to flatpack et al on https://kate-editor.org/get-it/ - and if Late is still built for flatpack, then we should explicitly state it's not supported and bug reports will simply be closed. AppImage is then the real solution, as all other solutions seem to add bugs to Kate from a user perspective (actually bad PR).
I've been using kate for over 15 years and i've never used any of those plugins, obviously i'm just 1 user, but just want to make you think you may be overstating the usefulness of something not so many people use and making it the core of the app hard to use for the rest that would like to use a flatpak. In my opinion the good solution would be detecting that git isn't available (doesn't matter if it's flatpak or not, it can be not installed in an old school distro as well) and then not expose the functionality (or give a meaningul error/tooltip/message/whatever of why it's not available). But that needs work and you're clearly not interested and personally neither am I (as said never used any of those plugins). I'll figure out if one can "remove" things from flathub.
I share Albert's sentiments. If nobody feels like putting work on it, there's no need to support it. It's a shame to ditch kate from flathub entirely because of these features who seem fringe to me, but big part of the reason to push for new formats is to empower the maintainers. I also feel it's a shame to consider that systems that disregard security measures are the way to go. But we're not going to solve this in this ticket.
Hi, thanks that you honor our request. I think it would be good to have Kate purged from flathub, I will remove the download link. For the other comments: 1) I don't consider e.g. the integrated (default on) konsole plugin or project plugin fringe stuff. And a terminal that is sandboxed without the user shell and user env is already not that useful, I at least won't be able to use this properly. Worse for the LSP stuff that we heavily promote. Having some checks that tell what is missing won't help, as the user won't be able to provide it, given we live in a sandbox. (if the user doesn't install a complete dev env in the home manually) And users will be heavily confused why we say "no clangd" if the have a global clangd and can use it perfectly well via vim/emacs/atom/... 2) For security: Kate already was allowed to access all files of the host => there is no security. With trivial code Kate could just patch the shell configs in your home and you will happily execute any exploit on the next start of any shell for the user. I don't think people should think they are secure just because they launched it via flatpak. That is only true of if the permissions are really heavily restricted. But I agree, if you have a app with a really strict limit on the stuff it can do, it is nice, e.g. perfect for some game or other application that doesn't need to work on your data, there really see the benefit. Or your Browser that can then only access ~/Downloads or such.
Git commit 38944e72a3ba26ad24a7770707799491f52169ca by Christoph Cullmann. Committed on 23/03/2021 at 18:40. Pushed by cullmann into branch 'master'. remove flatpak download link flatpak doesn't allow the access to the system/user environment this leads to severe issues for * the integrated terminal plugin (wrong shell, no user stuff in path, etc.) * the projects plugin (no access to the correct user installed svn/hg/git) * lsp plugin (no access to the user installed LSP servers) * external tools (no access to any external user tools) * small other stuff (the more tools/open with/...) therefore we will remove Kate from flathub/flatpak as long as this can't be rectified with "a lot" of work that might be possible, if somebody steps up and provides the necessary patches to tunnel out of the sandbox via portals or whatever one might reconsider this M +0 -4 content/get-it.en.md https://invent.kde.org/websites/kate-editor-org/commit/38944e72a3ba26ad24a7770707799491f52169ca
I wanted to note that there are other IDE tools in flathub like gnome builder or visual studio code and they generally work fine. Definitely using Sdk as runtime is the way to go for such case which give you access to cmake,git,perl,rust,go,clangd, etc.
Yeah, but not to the versions installed globally and used by any non-flatpak part of your system. E.g. no way to use kdesrc-build to build the kde stuff and then use Kate as IDE as that lives in a totally different universe. I am not saying that it makes no sense in general, but users shall be able to expect that Kate uses their version of these tools, not some different bundled one.
Isn't it possible use kdesrc-build inside flatpak first then use kate in the same environ?? There is also flatpak-spawn command to allows you to execute any command from host: https://manpages.debian.org/experimental/flatpak/flatpak-spawn.1.en.html
Btw. gnome builder goes to great lengths to try to emulate that system access: https://gitlab.gnome.org/GNOME/gnome-builder/-/commit/fee5214c927c841b66cfd34c0321b8c9890149ce If somebody steps up to do and maintain all such stuff for Kate, we can reconsider flatpak, but I see no team member with time for that. And I will rather spend time on stuff that improves life for all Kate users rather than working around issues due to some sand boxing flatpak enforces that provides no real security in our case anyways as we have full file access to the host.
(In reply to Ardith Metz from comment #22) > Isn't it possible use kdesrc-build inside flatpak first then use kate in the > same environ?? > > There is also flatpak-spawn command to allows you to execute any command > from host: > https://manpages.debian.org/experimental/flatpak/flatpak-spawn.1.en.html Then all the built stuff just runs in the flatpak env, that is even more strange and unexpected compared to a "normal" Kate install. Beside, as said, you can't use any system lib or script module not in the sdk. And as for the environment stuff of builder below: all extra stuff needed to work around the sand boxing is time we can spend better on other stuff. Beside if somebody volunteers to do it.
Generally flatpak is supposed to be self-contained and distro agnostic. If your system is debian then you can build something using debian tools that will work only on debian while other developer on fedora will work in totally different environ and another user on arch won't have a single binary that matched yours on their system. In flatpak you can build something using flatpak tools that will work everywhere flatpak works - that's the point of flatpak. That means every developer and user will share the same environment instead trying to keep people from 100 different environments on the same page. This is primary flatpak goal and all security et all is only secondary to that. I understand this may be not what you wanted and may not care about but may be worth to learn something about the platform kde releases its software for last couple years :)
Putting it differently: it's like running debian and complaining it doesn't use packages from fedora :)
How do you support, in flatpack, the build-plugin that can execute _any_ executable the user has access to on the system? It could be any of the build tools or a user generated script or even just any application... I agree with Christoph, that we can only re-enable the flatpack if there is someone willing to properly maintain the flatpack specific modifications and that the flatpack version does not have much degraded featureset. Do we have voluntarie(s) to do that?
To move things forward, I'm suggesting we keep Kate on Flathub but in a Beta state, where we can still try to improve support while at the same time making it clear to users that some features may not work. As Flathub maintainers, we try to keep Flatpak specific issues in the Flathub issues tracker so as upstream Kate developers, feel free to send users back to us for issues you can not or do not have time to fix. See also the discussion at https://invent.kde.org/teams/flathub/issues/-/issues/9
(In reply to Timothée Ravier from comment #28) > To move things forward, I'm suggesting we keep Kate on Flathub but in a Beta > state, where we can still try to improve support while at the same time > making it clear to users that some features may not work. > > As Flathub maintainers, we try to keep Flatpak specific issues in the > Flathub issues tracker so as upstream Kate developers, feel free to send > users back to us for issues you can not or do not have time to fix. > > See also the discussion at > https://invent.kde.org/teams/flathub/issues/-/issues/9 Please not. As long as nobody started to work on this, I don't want some Beta package that never is fixed. People ignore "Beta" classification and we will just have bad impressions left for people trying it. If somebody provides patches to have at least the terminal/projects/build/lsp stuff working properly, I am fine with trying this again. And these are not mere "niche" features, terminal & project are default on, LSP is one of the main selling points since 1-2 years. If they don't work properly, that is BAD. We did start to promote Kate on Windows only after we had something that works there. And yes, there the "terminal" is disabled, as Konsole is not yet ported, but all other stuff works as intended, naturally for the Windows Store variant, too, as that has no sandboxing.
We "fixed" this now by no longer providing Flatpak packages. Given there is the wish to have them again, I will keep this open as wishlist.
If we supported flatpak-spawn when running external commands, that would probably go a long way to addressing the issues that prompted this decision.
(In reply to Nate Graham from comment #31) > If we supported flatpak-spawn when running external commands, that would > probably go a long way to addressing the issues that prompted this decision. That might be true, thought e.g. already for the integrated terminal this seems not to work, if I don't misread e.g. https://github.com/alacritty/alacritty/issues/2571
And one thing to note: We have a lot of places that need love and will benefit all our users on Linux/BSD/Windows/macOS, therefore I personally will not work on this, I want to spend my time on stuff that helps a broader user base. If somebody steps up to do it and helps to maintain that code paths, sure, we can integrate such stuff (if one has this in some manageable way, actually, Qt should abstract this away in QProcess already...).
Yes, Konsole would need to gain flatpak-spawn support too. Then that would also work as expected. Abstracting this in QProcess is not a bad idea.
(In reply to Nate Graham from comment #34) > Yes, Konsole would need to gain flatpak-spawn support too. Then that would > also work as expected. As shown in that alacritty bug that seems not to be trivial. > > Abstracting this in QProcess is not a bad idea. An other point that will need love: We use e.g. findExecutable, too, to avoid bad stuff like executing a random binary in your path. That would need to work, too.
Good point!
Closing this one as the work will now mostly happen in Flathub. See https://invent.kde.org/teams/flathub/issues/-/issues/9#note_532977. Help for testing https://github.com/flathub/org.kde.kate/pull/24 is welcomed.