Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> I'm not generally against having an AppImage repository under the Geany > organisation, I just don't see the benefits and why it's worth the efforts to > migrate the already existing repository. > One option that may bear further discussion is what @eht16 mentioned above: >We could easily add the AppImage to >https://www.geany.org/download/third-party/ so that it gets more visible. Than >we are done with five minutes of work. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-943862635
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> Apart from that, I would recommend to not build new images on each push to > PRs or master branch. Yes thats why I suggest a different repository, its separate, so like Geany plugins doesn't get rebuilt with every Geany PR. Plus the points @kugel- noted. Now github allows transferring issues I just slide Mac ones to that repository. > Additionally, when Travis CI is used, you'll probably running out of free > credits quickly. Migrating to Github Actions could be a solution Agree it should use Github actions if being in the Geany organisation uses Geany Travis credits. That should happen before the repository is migrated. > I'm going to propose this also for the Geany repositories. Another issue, but agree it should be examined/tested. > Despite the general perception, technically it makes no difference and might > be even a wrong suggestion to the user. True, and at the moment the @ecmu scripts wget stuff from all sorts of places, that needs to become traceable if users are to be able to trust the resulting appimage. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-943848392
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I'm not generally against having an AppImage repository under the Geany organisation, I just don't see the benefits and why it's worth the efforts to migrate the already existing repository. I guess there will be the "official" argument but does it really matter that much? Despite the general perception, technically it makes no difference and might be even a wrong suggestion to the user. Why would be an AppImage repository in the Geany repository be more official than a repository elsewhere? It's still someone else who maintains it and there is not more or less QA, I think. Apart from that, I would recommend to *not* build new images on each push to PRs or master branch. This seems like a huge waste of resources. Additionally, when Travis CI is used, you'll probably running out of free credits quickly. Migrating to Github Actions could be a solution, I'm going to propose this also for the Geany repositories. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-943701014
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
IMO it would be good to have @ecmu work in the geany organisation, but in a separate repository. To me its like the MacOS images. We provide them, more or less with official blessing, but when it comes to support we must offload to @techee. At least the repo has its own set of issues and PRs -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-943642277
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I agree to volunteer in the support of Geany AppImage inside Geany organisation if this is possible. I am not an expert in github so I will need help to do that. Let me know... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-943547751
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Basically the Geany team does not have the effort available to support distribution, be it appimage, or flatpack, or snap. If somebody wants to make such distributions elsewhere, fine, but as @eht16 said the Geany team do _not_ accept the extra workload. > The AppImage team provides tools for upstream packaging, so that the original > authors of applications can provide binaries with end-to-end control over the > all aspects of the distribution. To be clear, the original authors do not want to have end to end control of the distribution, distribution is not our thing, Geany is a volunteer project where contributors work on what they want to, and so far most contributors have indicated no interest whatsoever in distribution. So including any distribution support in the main Geany repository is not desired. The only distribution in the Geany repo is windows, for historical reasons, and because it also requires source changes to support windows (see all the `#ifdef`s). Even the OSX build is outside the main repository. What I personally think might possibly be done (don't know what others think) is to provide another repository under the Geany organisation where someone who wants to support appimages can make them, similar to the way OSX is handled. But somebody has to offer to continue to support releasing them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-940774068
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
The AppImage team provides tools for upstream packaging, so that the original authors of applications can provide binaries with end-to-end control over the all aspects of the distribution. As a a general best practice measure for security, we discourage people from downloading software from "random places" which is everything but the original authors's download page. @ecmu has already put in the work and has made https://github.com/ecmu/geany.AppImage/blob/master/.travis.yml. Now it is a question of whether the Geany team would accept a PR to the official repository so that the AppImages would be officially created (and supported) by the Geany team. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-940715627
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
We also have https://github.com/geany/geany/discussions/2926 now. Where to continue the discussion? Until decided, I will add my remarks here. For me, https://github.com/geany/geany/issues/1303#issuecomment-260706578 and https://github.com/geany/geany/issues/1303#issuecomment-260731920 are still valid (even five years later). We already have more to do than we are able manage and putting even more work on us won't improve the situation. I still think we (the Geany developers) should focus on creating software and not on packaging. And as @b4n said before, if volunteers like @fusion809, @ecmu, @probonopd and whoever else might want to step in and provide AppImages, Flatpaks, Snaps, ZeroInstalls, ... that's completely fine. However, I don't see that those packaging efforts should happen within the Geany project itself. We could easily add the AppImage to https://www.geany.org/download/third-party/ so that it gets more visible. Than we are done with five minutes of work. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-940491149
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I'd encourage you to have both. The two formats are for completely different use cases. Here is a [comparison](https://github.com/AppImage/AppImageKit/wiki/Similar-projects). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-940309391
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I pondered over creating a flatpak for Geany. I'm not sure about the pros and cons of AppImage vs flatpak, though. What would be better, or can you usefully have both? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-939969918
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I see @ecmu just released [an updated Appimage for Geany 1.38.0](https://github.com/ecmu/geany.AppImage/releases/tag/1.38.0) Seems like it shouldn't be too difficult to merge that repo setup with Geany's official repo, so the AppImage would be more visible and available, etc. @eht16 @b4n -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-939533600
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> @kugel-: Well, I already do that in my repository : > https://github.com/ecmu/geany.AppImage Dude! YOU ROCK! Thank you so much! Your efforts are not in vain AppImage is such a great format, I wish it got more attention -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-714897464
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
An AppImage would be cool, @ecmu I starred your repo. :) Other people should too ;) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-504725576
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@kugel-: Well, I already do that in my repository : https://github.com/ecmu/geany.AppImage So I volunteer! What do you think about my work? I am quite new in github, so tell me what to do if you want it as Geany repository... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489587145
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@elextr @probonopd I would welcome if somebody steps up to provide an AppImage (based on releases) under the Geany umbrella. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489537733
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> packages are manually triggered That's the kind of manual work I want to avoid. > Are you really sure you want to do it every push? It's great for testing, yes. In fact, doing it right in the main repo would even do it for every pull request (but obviously put the download link URL only in the build log of that PR), which imho is an even greater advanatge. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489417904
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Are you really sure you want to do it every push? I'm not sure its good to inflict in-development stuff on users. Although we try to keep everything in master working, its not always the case, for example for some time prior to the 1.35 release several languages symbols didn't work, and the merge that fixed them broke several others which were only just fixed before release Perhaps its better to only build packages on releases. IIUC the OSX packages are manually triggered (but I'm not really sure, @techee should correct me if needed) and of course nothing for windows is built in Travis. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489417427
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Thanks for your detailed explanation @elextr. I would have no issues with it being in a separate repository; the only question is how can the separate repository be triggered to build when a `git push` happens to the main repository. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489413459
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> What I don't want to do is do "third-party packages". I am willing to help > the Geany project make official ones. Well, if its in a repository inside the Geany organisation like the OSX packaging is, that should be official enough. But as has been said before, the "Geany project" itself does not want to make distributions or include distribution support inside the main repository. Or rather, as the "Geany project" is a collection of volunteers, not a corporate supported entity with paid contributors, the volunteers have declined to use their own spare time for this purpose. And that applies to the Geany plugins collection as well. Whilst the Geany team has declined to volunteer to support making a distribution themselves, they have not said it should not be done and do not want to prevent it being done, as you can see from the level of assistance provided above to someone who did do it. Using a repository separate from both Geany and Geany-plugins would put the package in the same place for convenience. The maintainer of the package can be allowed to commit to that repository as the OSX maintainer does to the OSX repository, without having to make pull requests on the main repository. Pull requests on the main repository need contributors with commit rights to review and test it, and most of them have already stated that they are not interested in doing so for distribution packaging related things. By the way, that the windows packaging material is in the main repositories is purely historical, it might be nice to separate it too, but nobody has the time to spare to do that, so it will stay for now. But the originator of the windows packaging continues to support it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489412879
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Hi @elextr. @ecmu has done the work, and I am willing to work with the Geany project to bring it into the official Geany pipelines. Once it is there, it needs next to no continous maintenance, but if something breaks I will be there to fix it. What I don't want to do is do "third-party packages". I am willing to help the Geany project make official ones. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489408002
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@probonopd remember [this comment](https://github.com/geany/geany/issues/1303#issuecomment-260706578) and [this comment](https://github.com/geany/geany/issues/1303#issuecomment-260731920) are __you__ going to maintain it? If so then similar to the OSX support possibly we could provide a geany/appimage repository that you could use and, as said before, link to it from the website as we do for OSX. If not then please find someone else willing and capable of doing it, please stop trying to push the workload on to people who have already said they are not willing or able to do it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489406795
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Thanks @ecmu, your AppImage is running well for me. It's great to be able to just download one file and run the latest Geany, no matter the distribution.  @b4n would you be open to a pull request that would automatically build and upload an AppImage using Travis CI? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-489403928
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Thanks to @probonopd I created an AppImage for [geany](https://github.com/geany/geany) including [geany-plugins](https://github.com/geany/geany-plugins) using Travis-CI. Releases and source code can be found here: https://github.com/ecmu/geany.AppImage/releases Maybe these AppImages could be included directly into Geany releases ? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-451549204
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@b4n I also run `yum-builddep geany geany-plugins` before I start the build. So if that doesn't cause all the dependencies to be present I don't know what will. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262389989
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Just wanted to say that I really like the constructive collaboration here. Thank you @fusion809 and everyone and keep up the good work! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-263677329
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Sure, i was just posting *for the record* :p -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-263635742
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
It is for version 1.28, while my AppImage is for version 1.29 :). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-263635366
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
For the record, i've just stumbled on this snap "recipe" https://github.com/ubuntu/snappy-playpen/blob/geany/geany/snapcraft.yaml -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-263633737
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
On Arch Linux I get the error: ```bash (geany:1486): GLib-GIO-ERROR **: No GSettings schemas are installed on the system [1]1486 trace trap (core dumped) ./Geany* ``` when I start the web helper plugin. Any ideas? On Debian 8 and Fedora 24 VMs this error doesn't occur. This Arch Linux VM of mine in which I tested it does have `gsettings-desktop-schemas` installed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262643852
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Arch is a bleeding edge distro, maybe its version needs gsettings that older distros don't. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262662074
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
What are the compile flags you're using for WebKitGtk and GNOME libs? Maybe you got them wrong or are not self-compiling using binaries from one distro that are patched and/or incompatible with other distros (ex. using different paths for gsettings and such)? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262659091
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Yes, libicu is a direct dependency og WebKitGTK. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262636012
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
But it probably only works on Fedora because you already have the packages installed, if you didn't, it would probably be broken too. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262662460
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
You're right libicu is a dependency of WebKitGTK, which I know as without it the web helper plugin isn't available. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262636526
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Hum, I just realized `ctags-exuberant` might be needed for GeanyCTags to actually do something. Or maybe not, I'm not sure. > Can I delete OpenLDAP libs? I know very little about OpenLDAP but it seems to > be crypto-related. I guess you can (not totally sure of what those actually do, but still) > Oh and are libraries starting with `libicu` necessary? Not directly by anything in Geany, but that's possibly a dependency of e.g. WebKit, I don't know. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262633445
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I kept GDB in it, because it doesn't take up much space and it can be useful for debugging. If there's some security issue with it (like with GPG) or if different versions of it (as I am bundling a fairly old version of it) are vastly different (hence making it attractive to just let users take care of it as a dependency), as is the case with GCC, I will be willing to delete it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262638843
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I just updated the AppImage in my Bintray repo so you's can download it and try to find bugs in it (which is, of course, good, as bugs need to be corrected) and unneeded files https://bintray.com/fusion809/AppImages/download_file?file_path=Geany-1.29.glibc2.15-x86_64.AppImage. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262638039
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> I was able to cut its size down to just 39.62 MB by cutting out the WebKit > dependency. You get a lot of bang for your buck with WebKitGtk though. Not only are there 3 plugins that require it (Devhelp, Markdown and Webhelper), but also the version they need is going to be removed from Fedora sometime in the near future, meaning users won't be able to use these plugins unless they get them through another channel (like your AppImage). > Compression libraries (like zlib and liblzma) aren't required by Geany or its > plugins are they? I don't think directly, but GLib/GIO and probably some others depend on them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262695148
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> What about a list of runtime dependencies for `geany` and `geany-plugins` on > CentOS 7 that aren't X or GDK-related? If I had that I could satisfy both of > you, @b4n and @eht16. Geany has basically zero deps. You might want to bundle a version of `libvte9` because newer systems don't have that, but it's an optional runtime dependency for embedded terminal support. GP it's a whole different story. Check the libraries each plugins checks for. Or once built, run `ldd` or similar to see the deps list, and filter that using good judgment -- or use a better command that only lists direct dependencies, but I don't have that under the hand right now, yet I'm sure it exists, maybe some options for objdump? > Oh and which libraries included are X or GDK related? Out of: Basically, everything that starts with `libX` or `libx` is X-related, so is `pixman`. `libgdk` and `libatk` are GTK related, so are all of `pango`, `cairo`, `freetype`, `harfbuzz`, `png`. `EGL`, `gl` and `gbm` are OpenGL related, so X/GTK. `gmodule` and `gthread` are safe to assume I guess, GTK requires them anyway, and even many non-GUI apps. `libffi` is GLib-related, and we don't depend on it directly so again, no use. I have no clue about `libgraphite2` or `lzma` just now, but we don't depend on that directly either. Which leaves us with… `libgeany`. Better pack that last one :) But really, you should find a way to *automatically* list first-levels deps. LD must be able to help at some level, at least if building with `--as-needed` or something. > @b4n I also run `yum-builddep geany geany-plugins` before I start the build. > So if that doesn't cause all the build dependencies to be present I don't > know what will. Well, I can't know for sure, that must bring in what the author of the Fedora package said was required, that's all. If you want to ship some plugins, I really recommend using explicit `--enable-` flags so the configure pass explicitly fails if the dependencies aren't met. But I really think it's rather an improper target location for the actual plugin binaries that not building *any* GP plugins. > Well I've updated my AppImage to include the changes I think you want […] I > tested it on Arch Linux and it works on there now. It also works on Fedora > 24, so @b4n was right about those libraries. Good. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262395603
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Also tried it on openSUSE Tumbleweed and Debian 8 VMs without a problem. Both of which are fairly minimalistic too. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262664210
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Compression libraries (like `zlib` and `liblzma`) aren't required by Geany or its plugins are they? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262688458
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Mostly agree with @b4n gist except perhaps `usr/share/man/man1/geany.1.gz` :) Python 2.7 might (just barely) be useful since Geanypy needs it and some bleeding edge distros no longer provide it by default IIUC, although bleeding edge users are usually able to install stuff by themselves. Python3.x is not needed at all unless I am mistaken. As a general comment I would advise you to NEVER package GPG, ssl, tls or any other crypto stuff unless you are gonna update the package and push it to all users for every CVE thats fixed. You only included English spelling dictionaries, but people like @b4n use other strange languages (ie ones I can't understand :). Probably better to just not include any and let the user supply their favourite. As plugins only support webkitgtk 1 at the moment, and some distros (hi Fedora) are threatening to not support it any more, its probably worth including. With the above caveats @b4n's list of things to lose looks good. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262510351
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I can also confirm this plugin loads fine on Solus 1.2.1 and Sabayon Linux. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262665293
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I ran `find /usr -name "*gsettings*"` on Fedora 24 (on which the web helper plugin is working fine) and got: http://paste2.org/HxbJ9tEb. While on Arch Linux that same search gave: http://paste2.org/LUxjb3am. To me these two searches look much the same. Any idea which file might be the problem? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262660872
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Oh and are libraries starting with `libicu` necessary? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262632358
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Well Arch Linux isn't really all too important to support to me as they have the latest Geany and its plugins in their repos anyway. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262662374
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Neither of those show the actual compiled GSettings schemas. Presumably if you're on Fedora (GNOME-heavy distro), you should have many. On Xubuntu I have 87 schemas under `/usr/share/glib-2.0/schemas` and have barely any GNOME apps. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262662091
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
`LD_DEBUG=libs ./*AppImage` gave: ```bash 1774: calling init: /usr/lib/gio/modules/libgiognomeproxy.so 1774: 1774: /usr/lib/gio/modules/libgiognomeproxy.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 1774: /usr/lib/gio/modules/libgiognomeproxy.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) (geany:1774): GLib-GIO-ERROR **: No GSettings schemas are installed on the system ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262648183
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I didn't compile it. I'm using WebKitGtk and GNOME libs from the Ubuntu 14.04 repos. But I will look to see if you might be right on different file paths. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262660206
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
This Fedora VM of mine is minimalistic. The only pieces of software I installed on top of the default set of apps (I installed the GNOME edition) are Git, Zsh and OpenSSH. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262662690
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I've been able to cut down on its size from 84 MB to 65 MB. Here is my yaml: ```yaml app: Geany binpatch: true ingredients: packages: - geany - geany-plugins - python-gtk2 dist: trusty sources: - deb http://archive.ubuntu.com/ubuntu/ trusty main universe ppas: - brentonhorne/geany2 script: - cp ./usr/share/icons/hicolor/scalable/apps/geany.svg . - rm -rf ./bin/ - rm ./usr/bin/[ ./usr/bin/arch ./usr/bin/base64 ./usr/bin/basename ./usr/bin/chcon ./usr/bin/cksum ./usr/bin/comm ./usr/bin/csplit ./usr/bin/ctags-exuberant ./usr/bin/cut ./usr/bin/dh_python2 ./usr/bin/dircolors ./usr/bin/dirname ./usr/bin/du ./usr/bin/env ./usr/bin/expand ./usr/bin/expr ./usr/bin/factor ./usr/bin/fmt ./usr/bin/fold ./usr/bin/gcore ./usr/bin/groups ./usr/bin/head ./usr/bin/hostid ./usr/bin/id ./usr/bin/install ./usr/bin/join ./usr/bin/lcf ./usr/bin/link ./usr/bin/logname ./usr/bin/lspgpot ./usr/bin/md5sum* ./usr/bin/mkfifo ./usr/bin/nice ./usr/bin/nl ./usr/bin/nohup ./usr/bin/nproc ./usr/bin/numfmt ./usr/bin/od ./usr/bin/pathchk ./usr/bin/pinky ./usr/bin/pr ./usr/bin/precat ./usr/bin/preunzip ./usr/bin/prezip* ./usr/bin/printenv ./usr/bin/printf ./usr/bin/ptx ./usr/bin/runcon ./usr/bin/seq ./usr/bin/sha*sum ./usr/bin/shred ./usr/bin/shuf ./usr/bin/sort ./usr/bin/split ./usr/bin/stat ./usr/bin/stdbuf ./usr/bin/sum ./usr/bin/tac ./usr/bin/tail ./usr/bin/tee ./usr/bin/test ./usr/bin/timeout ./usr/bin/touch ./usr/bin/tr ./usr/bin/truncate ./usr/bin/tsort ./usr/bin/tty ./usr/bin/unexpand ./usr/bin/uniq ./usr/bin/unlink ./usr/bin/users ./usr/bin/wc ./usr/bin/who* ./usr/bin/X11 ./usr/bin/yes - rm -rf ./usr/lib/python3.4 ./usr/share/doc ./usr/share/man ./usr/share/locale - rm -rf ./usr/share/aspell ./var/lib/aspell ./usr/lib/aspell ./usr/bin/*aspell* ./usr/share/info ./usr/share/enchant ./usr/share/doc-base - rm -rf ./usr/share/gconf ./usr/share/bug ./usr/share/debhelper ./usr/share/perl5 ./usr/share/dbus-1 ./usr/share/applications ./usr/share/lintian ./usr/share/X11 ./usr/share/readline ./usr/share/sgml ./usr/share/gnupg ./usr/lib/gnupg ./usr/bin/gpg* - rm -rf ./etc/gconf ./etc/python3.4 ./etc/X11 - rm -rf ./usr/sbin ./usr/lib/sasl2 ./usr/lib/coreutils ./usr/lib/X11 ./usr/lib/x86_64-linux-gnu/enchant ./usr/lib/x86_64-linux-gnu/gconf ./usr/lib/x86_64-linux-gnu/openssl-1.0.0 ./usr/lib/x86_64-linux-gnu/sasl2 - rm ./usr/lib/x86_64-linux-gnu/*dbus* ./usr/lib/x86_64-linux-gnu/*enchant* ./usr/lib/x86_64-linux-gnu/libgpgme* ./usr/lib/x86_64-linux-gnu/libgraphite* ./usr/lib/x86_64-linux-gnu/libhunspell* ./usr/lib/x86_64-linux-gnu/libpython3.4* ./usr/lib/x86_64-linux-gnu/*sasl2* ./usr/lib/x86_64-linux-gnu/*xslt* ./usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0 ./usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0.0.0 ./usr/lib/x86_64-linux-gnu/libsecret-1* - rm ./usr/lib/*spell* - rm -rf ./var/lib/dictionaries-common ./var/lib/gconf - rm ./lib/x86_64-linux-gnu/libreadline* ``` I shared it because under the `script` section you can see what I have deleted from the AppImage. Every time I deleted something new I tested it out in a Debian 8 (with KDE Plasma 4) and Fedora 24 VM (with GNOME 3.20) that have the minimum amount of software installed (so as to make these tests fair) and found nothing to have gone awry. Can I delete OpenLDAP libs? I know very little about OpenLDAP but it seems to be crypto-related. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262631534
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I was able to cut its size down to just 39.62 MB by cutting out the WebKit dependency. I found that on Frugalware Linux the web helper plugin wouldn't load unless webkit-gtk2 was installed locally, even when I still bundled webkit with the AppImage. Here is my yaml now: ```yaml app: Geany union: true ingredients: packages: - geany - geany-plugins - python-gtk2 dist: trusty sources: - deb http://archive.ubuntu.com/ubuntu/ trusty main universe ppas: - brentonhorne/geany2 script: - cp ./usr/share/icons/hicolor/scalable/apps/geany.svg . - rm -rf ./bin/ - rm ./usr/bin/[ ./usr/bin/arch ./usr/bin/base64 ./usr/bin/basename ./usr/bin/chcon ./usr/bin/cksum ./usr/bin/comm ./usr/bin/csplit ./usr/bin/cut ./usr/bin/dh_python2 ./usr/bin/dircolors ./usr/bin/dirname ./usr/bin/du ./usr/bin/env ./usr/bin/expand ./usr/bin/expr ./usr/bin/factor ./usr/bin/fmt ./usr/bin/fold ./usr/bin/gcore ./usr/bin/groups ./usr/bin/head ./usr/bin/hostid ./usr/bin/id ./usr/bin/install ./usr/bin/join ./usr/bin/lcf ./usr/bin/link ./usr/bin/logname ./usr/bin/lspgpot ./usr/bin/md5sum* ./usr/bin/mkfifo ./usr/bin/nice ./usr/bin/nl ./usr/bin/nohup ./usr/bin/nproc ./usr/bin/numfmt ./usr/bin/od ./usr/bin/pathchk ./usr/bin/pinky ./usr/bin/pr ./usr/bin/precat ./usr/bin/preunzip ./usr/bin/prezip* ./usr/bin/printenv ./usr/bin/printf ./usr/bin/ptx ./usr/bin/runcon ./usr/bin/seq ./usr/bin/sha*sum ./usr/bin/shred ./usr/bin/shuf ./usr/bin/sort ./usr/bin/split ./usr/bin/stat ./usr/bin/stdbuf ./usr/bin/sum ./usr/bin/tac ./usr/bin/tail ./usr/bin/tee ./usr/bin/test ./usr/bin/gdb* ./usr/bin/gpg* ./usr/bin/timeout ./usr/bin/touch ./usr/bin/tr ./usr/bin/truncate ./usr/bin/tsort ./usr/bin/tty ./usr/bin/unexpand ./usr/bin/uniq ./usr/bin/unlink ./usr/bin/users ./usr/bin/wc ./usr/bin/who* ./usr/bin/X11 ./usr/bin/yes - rm -rf ./usr/lib/python3.4 ./usr/share/doc ./usr/share/man ./usr/share/locale - rm -rf ./usr/share/aspell ./var/lib/aspell ./usr/lib/aspell ./usr/bin/*aspell* ./usr/share/info ./usr/share/enchant ./usr/share/doc-base - rm -rf ./usr/share/gconf ./usr/share/bug ./usr/share/debhelper ./usr/share/perl5 ./usr/share/dbus-1 ./usr/share/applications ./usr/share/lintian ./usr/share/X11 ./usr/share/readline ./usr/share/sgml ./usr/share/gnupg ./usr/lib/gnupg ./usr/share/webkitgtk* ./usr/share/apps ./usr/share/gdb - rm -rf ./etc/gconf ./etc/python3.4 ./etc/X11 - rm -rf ./usr/sbin ./usr/lib/sasl2 ./usr/lib/coreutils ./usr/lib/X11 ./usr/lib/x86_64-linux-gnu/enchant ./usr/lib/x86_64-linux-gnu/gconf ./usr/lib/x86_64-linux-gnu/openssl-1.0.0 ./usr/lib/x86_64-linux-gnu/sasl2 ./var - rm ./usr/lib/x86_64-linux-gnu/*dbus* ./usr/lib/x86_64-linux-gnu/*enchant* ./usr/lib/x86_64-linux-gnu/libgpgme* ./usr/lib/x86_64-linux-gnu/libgraphite* ./usr/lib/x86_64-linux-gnu/libhunspell* ./usr/lib/x86_64-linux-gnu/libpython3.4* ./usr/lib/x86_64-linux-gnu/*sasl2* ./usr/lib/x86_64-linux-gnu/*xslt* ./usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0 ./usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0.0.0 ./usr/lib/x86_64-linux-gnu/libsecret-1* ./usr/lib/x86_64-linux-gnu/libX* ./usr/lib/x86_64-linux-gnu/libxcb-util* ./usr/lib/x86_64-linux-gnu/libharfbuzz* ./usr/lib/x86_64-linux-gnu/libfreetype* ./usr/lib/x86_64-linux-gnu/libgconf* ./usr/lib/x86_64-linux-gnu/libICE* ./usr/lib/x86_64-linux-gnu/libicu* ./usr/lib/x86_64-linux-gnu/*gtk* - rm ./usr/lib/*spell* - rm ./lib/x86_64-linux-gnu/libreadline* ./lib/x86_64-linux-gnu/*ssl* ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262679765
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
4 monthly updates seem easy to maintain so yeah I do plan to. Unless of course newer releases break compatibility with CentOS 7's GCC compiler and set of libraries. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262382789
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> Oh and if those plugins are missing then it's the fault of your build system > fork `geany-plugins`. The build system doesn't enable any plugin if they have a missing dependency, but some plugins don't have any extra deps. It rather sounds like you didn't properly build GP against the Geany you just built, and it tried to install plugin files into the system's Geany's libdir (as it has to put them there for Geany to find them, even if it's outside PREFIX). best suggestion is to override `PKG_CONFIG_PATH` to point to the custom built Geany's *lib/pkgconfig*. Alternatively, use `--with-geany-libdir=PATH` configure option. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262385245
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
What about a list of runtime dependencies for `geany` and `geany-plugins` that aren't X or GDK-related? If I had that I could satisfy both of you. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262387147
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Thanks a million, now it works. Here is the link https://bintray.com/fusion809/AppImages/Geany#files. It is much larger than my CentOS one, it is ~88 MB in size. If you can find files in it that I can delete to make it smaller, feel free. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262430589
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
GeanyPy [requires PyGTK](https://github.com/geany/geany-plugins/blob/master/build/geanypy.m4#L5) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262428374
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
They're included because without GDK libraries I get an error on Fedora 24. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262384644
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I have tried bundling VTE and other geany plugins deps and I found they weren't being loaded. For example, there was no terminal embedded in Geany, hence indicating that VTE wasn't being loaded. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262400857
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> see the archive contents at http://pastebin.geany.org/TDiF5/ I really wonder why X11 and GDK are included here, all those should be assumed to be present just fine. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262384399
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Sorry, I don't know CentOS 7. But I guess you'll be able to figure out the proper package names. Or if you don't like to, then just skip the dependencies. I don't mind much. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262400989
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Didn't you read what I said? I am using a CentOS 7 VM not Debian. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262400405
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> Yeah I increased its size to 112M by including gcc, g++ and make in it Hum… I'm not sure if it's really sensible to do so, because if people want to develop apps in C or C++ they'll likely need development files for other libraries and alike. Also, you could then consider including Python, Ruby, gfortran and whatnot. But well, that's my thought right now, maybe it's useful to some. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262475639
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Thanks when I wake up tomorrow I'll analyse your suggestions in detail. If anyone else wants to throw in their two cents I'll be happy to consider them too tomorrow. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262494008
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Well I've updated my AppImage to include the changes I think you want (as I won't know until you actually give me more details like the list of geany plugins dependencies on CentOS 7) https://bintray.com/fusion809/AppImages/Geany#files. I tested it on Arch Linux and it works on there now. It also works on Fedora 24, so @b4n was right about those libraries. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262392469
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> If you can find files in it that I can delete to make it smaller, feel free. things that look useless/weird to me: https://gist.github.com/b4n/0b1f3b7de98c5c6c19449566eb18e6a9 I'm not saying none of those would be required (like, maybe webkit depends on *libwebp* for example), but I don't think those are direct dependencies. Worth checking they really aren't common (and anything under *lib/* *is* common). Other stuff I have questions about: ## Python stuff ``` usr/bin/2to3 usr/bin/2to3-2.7 usr/bin/pdb usr/bin/pdb2.7 usr/bin/pyclean usr/bin/pycompile usr/bin/pydoc usr/bin/pydoc2.7 usr/bin/pygettext usr/bin/pygettext2.7 usr/bin/python usr/bin/python2 usr/bin/python2.7 usr/bin/pyversions usr/lib/valgrind/python.supp usr/lib/x86_64-linux-gnu/libpython2.7.a usr/lib/x86_64-linux-gnu/libpython2.7.so usr/lib/x86_64-linux-gnu/libpython2.7.so.1 usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 usr/lib/x86_64-linux-gnu/libpython3.4m.so.1 usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 ``` And basically everything under *usr/lib/python2.7/* and *usr/lib/python3.4/*. Maybe *some* of that *might* be required for non-standard things, maybe 2to3, but a lot shouldn't be needed. ## GeanyPG? It would be useful to check if some of that is actually needed. Distributing things as sensible as GPG seem somewhat hazardous to me. ``` usr/bin/gpg usr/bin/gpg-zip usr/bin/gpgsplit usr/bin/gpgv usr/lib/gnupg/gpgkeys_curl usr/lib/gnupg/gpgkeys_finger usr/lib/gnupg/gpgkeys_hkp usr/lib/gnupg/gpgkeys_ldap usr/lib/gnupg/gpgkeys_mailto ``` ## For debugger plugins? But hum, similar to bundling GCC, I'm not quite sure it's useful. ``` etc/gdb/gdbinit usr/bin/gdb usr/bin/gdbtui ``` ## WebHelper That's probably OK, but might end up huge, esp. as it might bring in many additional stuff ``` usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0 usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0.16.8 usr/lib/x86_64-linux-gnu/libwebkitgtk-1.0.so.0 usr/lib/x86_64-linux-gnu/libwebkitgtk-1.0.so.0.22.6 usr/share/webkitgtk-1.0/images/deleteButton.png usr/share/webkitgtk-1.0/images/inputSpeech.png usr/share/webkitgtk-1.0/images/missingImage.png usr/share/webkitgtk-1.0/images/nullPlugin.png usr/share/webkitgtk-1.0/images/panIcon.png usr/share/webkitgtk-1.0/images/textAreaResizeCorner.png usr/share/webkitgtk-1.0/images/urlIcon.png usr/share/webkitgtk-1.0/resources/error.html usr/share/webkitgtk-1.0/resources/audio/Composite.wav ``` ## GeanyLua I don't think the "c++" versions would be used. ``` usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0 usr/lib/x86_64-linux-gnu/liblua5.1-c++.so.0.0.0 ``` ## Spellcheck What of those are actually needed? ``` usr/share/aspell/aspell.compat usr/share/aspell/en-common.cwl.gz usr/share/aspell/en-variant_0.cwl.gz usr/share/aspell/en-variant_1.cwl.gz usr/share/aspell/en-variant_2.cwl.gz usr/share/aspell/en-w_accents-only.cwl.gz usr/share/aspell/en-wo_accents-only.cwl.gz usr/share/aspell/en.contents usr/share/aspell/en_CA-variant_0.cwl.gz usr/share/aspell/en_CA-variant_1.cwl.gz usr/share/aspell/en_CA-w_accents-only.cwl.gz usr/share/aspell/en_CA-wo_accents-only.cwl.gz usr/share/aspell/en_GB-ise-w_accents-only.cwl.gz usr/share/aspell/en_GB-ise-wo_accents-only.cwl.gz usr/share/aspell/en_GB-ize-w_accents-only.cwl.gz usr/share/aspell/en_GB-ize-wo_accents-only.cwl.gz usr/share/aspell/en_GB-variant_0.cwl.gz usr/share/aspell/en_GB-variant_1.cwl.gz usr/share/aspell/en_US-w_accents-only.cwl.gz usr/share/aspell/en_US-wo_accents-only.cwl.gz var/lib/aspell/en-common.rws var/lib/aspell/en-variant_0.rws var/lib/aspell/en-variant_1.rws var/lib/aspell/en-variant_2.rws var/lib/aspell/en-w_accents-only.rws var/lib/aspell/en-wo_accents-only.rws var/lib/aspell/en.compat var/lib/aspell/en_CA-variant_0.rws var/lib/aspell/en_CA-variant_1.rws var/lib/aspell/en_CA-w_accents-only.rws var/lib/aspell/en_CA-wo_accents-only.rws var/lib/aspell/en_GB-ise-w_accents-only.rws var/lib/aspell/en_GB-ise-wo_accents-only.rws var/lib/aspell/en_GB-ize-w_accents-only.rws var/lib/aspell/en_GB-ize-wo_accents-only.rws var/lib/aspell/en_GB-variant_0.rws var/lib/aspell/en_GB-variant_1.rws var/lib/aspell/en_US-w_accents-only.rws var/lib/aspell/en_US-wo_accents-only.rws ``` ## *usr/share/doc/* Stuff under *usr/share/doc/* directly depend on what ends up included. ## *usr/share/man* Somewhat the same as for *usr/share/doc/* for usr/share/man, but that's fairly less useful ## GConf2 GConf2 client library might be useful for DevHelp, but I'm not sure it's of any use to pack server and all. I'm not even sure that code is used, and it depends if it's meant to read settings only or save them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262492130
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Yeah I increased its size to 112M by including gcc, g++ and make in it, so people can build C/C++ projects in it too. Merely run `bsdtar -xf ` to get the contents. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262474057
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Done 1.29.glibc2.15 was just published https://bintray.com/fusion809/AppImages/Geany#files. It's at 84 MB. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262480575
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I've found that by compiling some extra packages I can get a little further towards the goal of getting all plugins to work. The geanypy plugin is causing problems still though, giving the error: ```bash 2432: /tmp/.mount_dKVgoK/usr/lib/geany/geanypy.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 2432: /tmp/.mount_dKVgoK/usr/lib/geany/geanypy.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) ``` any ideas why? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262424196
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@fusion809 - I don't mind much about the capitalisation, I didn't consider the names as package names. Then it is OK probably. - I still vote for "Free Software" as it is more specific than this ambigous term "open-source". And here the capitalisation is actually important. - in the latest image the plugin library files are included but in usr/lib/geany/geany/; Geany looks in usr/lib/geany - interestingly, the GeanyPy library file is still usr/lib/geany; trying to load it will crash Geany: ``` [0:42:27] enrico@endor (1): /tmp% ./geany-1.29.0.glibc2.17-x86_64.AppImage -vc /tmp/gpt zenity, kdialog, Xdialog missing. Skipping ./bin//geany.wrapper. Geany-INFO: Using alternate configuration directory Geany-INFO: Geany 1.29, en_GB.utf8 Geany-INFO: GTK 2.24.31, GLib 2.50.1 Geany-INFO: System data dir: /tmp/.mount_gCSUqm/usr/share/geany Geany-INFO: User config dir: /tmp/gpt Geany-INFO: System plugin path: /tmp/.mount_gCSUqm/usr/lib/geany Geany-INFO: Added filetype Clojure (61). Geany-INFO: Added filetype CUDA (62). Geany-INFO: Added filetype Cython (63). Geany-INFO: Added filetype Genie (64). Geany-INFO: Added filetype Graphviz (65). Geany-INFO: Added filetype JSON (66). Geany-INFO: Added filetype Scala (67). Geany-INFO: Loaded libvte from libvte.so Geany-INFO: unknown : None (UTF-8) Geany-INFO: Added 7 plugin(s) in '/tmp/.mount_gCSUqm/usr/lib/geany'. zsh: segmentation fault (core dumped) ./geany-1.29.0.glibc2.17-x86_64.AppImage -vc /tmp/gpt ``` Regarding the plugin dependencies: `apt-get build-dep geany-plugins` should help or alternatively, https://anonscm.debian.org/git/pkg-geany/packages/geany-plugins.git/tree/debian/control#n6. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262400225
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I used lowercase as `geany` and `geany-plugins` are more package names than they are program names. geany-plugins shouldn't be capitalized even if we disregard the fact I'm talking about packages, as they're not a proper noun. If I had a list of runtime dependencies for these plugins for CentOS 7 I would, but I don't have one. Please do provide one though. As for your Arch Linux error well I think it might relate to blacklisted libraries that I'm talking to the upstream developer of AppImages about. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262381268
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
You possibly somehow have used a version of Glib that doesn't support [g_module](https://developer.gnome.org/glib/stable/glib-Dynamic-Loading-of-Modules.html) though how I have no idea, every Linux I have seen supports it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262426043
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> Is there a way to enable all plugins without specifying them each > individually? Yes, `--enable-all-plugins`. > I have tried bundling VTE […] and I found they weren't being loaded. For > example, there was no terminal embedded in Geany, hence indicating that VTE > wasn't being loaded. Note that for a GTK2 build of Geany you need *libvte.so.9*, not one of the *libvte2** ones. > The geanypy plugin is causing problems still though, giving the error: ```bash 2432: /tmp/.mount_dKVgoK/usr/lib/geany/geanypy.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 2432: /tmp/.mount_dKVgoK/usr/lib/geany/geanypy.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) ``` > > any ideas why? That's weird, those 2 symbols aren't supposed to be depended upon, but optionally present in modules loaded by GModule. See https://developer.gnome.org/glib/unstable/glib-Dynamic-Loading-of-Modules.html#GModuleCheckInit > Here is the link https://bintray.com/fusion809/AppImages/Geany#files. It is > much larger than my CentOS one, it is ~88 MB in size. If you can find files > in it that I can delete to make it smaller, feel free. The link says 1.29 is 112M, no 88. Anyway, how do I get a list of files in that archive? Or simply, how do I unpack it? (I see @eht16 did that, but I don't know how I'd do it) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262471657
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Is there a way to enable all plugins without specifying them each individually? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262399050
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
A few comments before adding it to the website: - when running on ArchLinux I get: ``` zenity, kdialog, Xdialog missing. Skipping ./bin//geany.wrapper. /tmp/.mount_3N7xOv/usr/bin/geany: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory ``` As a user I wouldn't expect I need SELinux for running Geany. Though not a strong opinion on this. - the description on the website https://bintray.com/fusion809/AppImages/Geany/ tells "A lightweight, open-source IDE". If it all, it should be "Free Software" not "open-source", please - also in the description, it should read "Geany and Geany-Plugins". Not that the uppercase matters much but it reads nicer to me (but I'm not a native speaker, so @elextr might correct me here) - looking inside the archive, I noticed the only plugin from Geany-Plugins is GeanyPy; all other plugins are missing in lib/geany however usr/share/doc/geany-plugins knows about much more plugins which are not actually included; see the archive contents at http://pastebin.geany.org/TDiF5/ - if you want to distribute the plugins together, you might consider installing some more dependencies, at least easy dependencies, I don't suggest things like WebKitGTK or so To put it on the website, I'd wish a little more love given to the package. @fusion809 do you think you will continue providing such images also in the future? We have Geany releases every four months, so ideally you would update the image then as well. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262378922
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> They're included because without GDK libraries I get an error on Fedora 24. As said on https://github.com/probonopd/AppImages/issues/145#issuecomment-262383994 I really doubt it's because F24 doesn't have this lib, but rather because you pack other outdated libs F24's version of it depend on. Just don't pack anything you don't know why you would IMO. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262385776
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Well that's a relief, I don't like to bundle extra stuff if I don't have to. I just made a commit so Travis CI should be building it now and uploading it to Bintray. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262477937
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Oh and which libraries included are X or GDK related? Out of: ```bash libEGL.so.1 libX11-xcb.so.1 libXau.so.6 libXcomposite.so.1 libXcursor.so.1 libXdamage.so.1 libXext.so.6 libXfixes.so.3 libXi.so.6 libXinerama.so.1 libXrandr.so.2 libXrender.so.1 libXxf86vm.so.1 libatk-1.0.so.0 libcairo.so.2 libffi.so.6 libfreetype.so.6 libgbm.so.1 libgdk-x11-2.0.so.0 libgeany.la libgeany.so -> libgeany.so.0.0.0 libgeany.so.0 -> libgeany.so.0.0.0 libgeany.so.0.0.0 libglapi.so.0 libgmodule-2.0.so.0 libgraphite2.so.3 libgthread-2.0.so.0 libharfbuzz.so.0 liblzma.so.5 libpango-1.0.so.0 libpangocairo-1.0.so.0 libpangoft2-1.0.so.0 libpcre.so.1 libpixman-1.so.0 libpng15.so.15 libxcb-dri2.so.0 libxcb-dri3.so.0 libxcb-glx.so.0 libxcb-present.so.0 libxcb-randr.so.0 libxcb-render.so.0 libxcb-shape.so.0 libxcb-shm.so.0 libxcb-sync.so.1 libxcb-xfixes.so.0 libxshmfence.so.1 ``` guessing everyone with `xcb` and `X` in its name? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262387882
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
My build using Ubuntu 14.04 is working better than this CentOS build. The only error I get is when loading GeanyPy, the terminal works fine (unlike my CentOS build in which it has a most peculiar bug) and other plugins seem to work fine. Here is my GeanyPy error: ```bash ImportError: could not import gobject (error was: 'No module named gobject') ImportError: No module named geany (geany:2909): GeanyPy-WARNING **: Unable to import 'geany' module ImportError: No module named geany.plugin ``` Does there need to be a geany plugin available in `/usr/lib/python2.7/`? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262426643
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Geany packages in the CentOS ep7 repos that I have enabled are for version 1.28 so assuming no major changes since then it shouldn't be out-of-date. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262397957
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Yeah, its not a good idea to package random compiler versions, they may not be compatible with the system libraries and includes on the user system that have been compiled with the system compiler. Frankly C/C++ developers on Linux are probably the least likely to need packaged compilers. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262476750
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Oh and if those plugins are missing then it's the fault of your build system for Geany Plugins. I compiled both Geany and Geany plugins from source code and installed them to the AppDir directory (which has the structure you showed at that external link) via the `--prefix` setting for configure to `/AppDir/usr`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262381728
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I have built a working AppImage for Geany 1.29 that I have tested successfully on CentOS 7, Debian 8, Fedora 24, openSUSE 42.1, Ubuntu 16.04 and Ubuntu 16.10 VMs. It was built on a CentOS 7 VM so it should work on any distribution of equal age or newer than this one (so Arch Linux, CentOS 7, Debian 8, Gentoo Linux, openSUSE ≥42.1, Sabayon Linux and Ubuntu, to name a few), provided it has FUSE set up. I'm mentioning this because you may wish to include it in your ThirdPartyPackages article https://www.geany.org/Download/ThirdPartyPackages. Here is its URL https://bintray.com/fusion809/AppImages/Geany/1.29.0.glibc2.17/view/files. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262079479
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Yeah new releases will be at https://bintray.com/fusion809/AppImages/Geany/. So that's probably a better link to provide at that ThirdPartyPackages page. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262107464
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Then you should document that both are included on your downloads page, so you can bask in the glory and appreciation of users, not expect people to read the build script to find out why there is no plugins package. :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262113004
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@fusion809 Good job, thank you. By the way, despite its name, the geany-dev PPA is not owned or operated by the Geany team and its owner seems to be having difficulty keeping up since Geany moved to several releases per year. @eht16 is it you I ping re adding website links to these packages? And maybe we should check validity of the other links. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262105692
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Rofl, the package contains both. I can even show you the Recipe I used to build it https://github.com/fusion809/AppImages/blob/master/recipes/geany-centos7/Recipe. As you can see I installed both `geany` and `geany-plugins` to the AppDir directory. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262111678
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@fusion809 now I don't want to seem greedy, but, what about geany-plugins? :smile: Also, just a note, make sure you comply with any requirements of licenses of dependencies you package. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262110395
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
I also own a PPA for Ubuntu 14.04 and 16.04 that provides Geany 1.29, which is newer than the Geany 1.27 provided by `geany-dev/ppa`. Its Launchpad URL is https://launchpad.net/~brentonhorne/+archive/ubuntu/geany2. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262085904
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
Sure. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-262113423
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@probonopd you seem obsessed with users, as if Geany was a commercial software product. Let me agree with Richard Stallman the father of open source development, "We build the software because we want to, or because it provides functionality we need/want, we are happy that it is useful to others, but we do not gain from users, in fact we may incur a support cost. Similarly we are sad for them if someone cannot/does not use our software, but we do not lose by that. Chasing users is not our purpose" If an individual wants to provide extra functionality such as packages for users (as @fusion809 is doing ), well, thats why its open source, to allow them to do so. We are happy to incorporate low impact pull requests if something is preventing that. But we are not interested in providing packaging and leave it to those who are. As @b4n has demonstrated we are happy to advise and help them with it. But we will not take over maintenance of the package from them. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260826301
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> you seem obsessed with users @elextr indeed, you got me there :-) > as if Geany was a commercial software product Why would a polished user experience be only relevant for a _commercial_ software product? There are many examples where open source software is more polished than commercial counterparts, unfortunately desktop software is often not in this camp (yet?). > Richard Stallman the father of open source development Don't let him hear that ;-) being the father of the "Free Software" movement. He is (rightfully) concerned about openness. His point is that without the source code, software is worthless (to him). My point is that to the average user, without (easily) working binaries, software is useless (to them). Truth be told, this may be less of a concern for an IDE which is focusing on developers as the target group. Personally I am convinced that a polished end user experience requires that there is no split between the people who develop (and understand the inner working of) software and the people who build the software and try to distribute it to end users. There are even extreme cases where upstreams have _forbidden_ distributions to change (and thus, subtly break) their software due to some distribution policies. In general, though, this notion of "only commercial software has to be a polished end user experience" guarantees that Linux will remain a tiny niche on the desktop. Sorry if this was half-OT. That being said, I respect that projects are driven by volunteers and volunteers do what volunteers do. That's OK for me, as I am a volunteer myself. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260855171
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@probonopd thank for the polite disagreement and discussion, its sometimes rare. I suspect we will have to end up agreeing to disagree. You are interested in the USER, we are developers and interested in DEVELOPMENT and the experience of running the software and its functionality. We don't claim to know packaging, nor do we want to do so. As volunteer developers that is our prerogative. (That is of course a black and white statement about a group of contributors, and so in reality the lack of interest may vary between individuals and circumstances, but this and other previous discussions have seen most of the main contributors be negative about being involved in packaging.) But as noted previously we are happy for others with expertise and interest to try to improve the user packaging experience and will assist them with problems they encounter. Though it is my personal experience that the centralised Linux package experience is far superior to the Windows one of having to find the individual software items site, then download from there with varying levels of quality and support for OS versions. Duplicating that in Linux is not going to improve the Linux experience, especially with the plethora of releases of a plethora of distros, on which the package may or may not work, but the upstream can't tell since they don't have all versions of all distros to test so the user is left with failing packages on some systems. But that is of course my own opinion. PS The "Free Software" movement is a subset and progenitor of the wider "open source" movement, so RMS is not gonna be allowed to dodge responsibility for the whole shebang, as much as he hates it :) (An aside, the difference mirrors the discussion above, Free Software gives users freedom at the expense of restricting developers freedom, open source gives developers freedom to restrict users freedom. I can argue the relative merits of these forever, but this isn't the forum for that and @b4n would get grumpy with me :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260863403
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> There are [a couple of > options](https://github.com/probonopd/AppImageKit/issues/267) for that. Nice :) > But wouldn't it be the cleanest solution to solve it right in the source code > from the beginning, by not using absolute paths? (How is it done for macOS)? Well. We do use [dynamic paths](https://github.com/geany/geany/blob/master/src/utils.c#L2092) indeed to support Windows and OSX, and as said we do have [binary relocation support already](https://github.com/geany/geany/blob/master/src/prefix.c). But one tricky part is finding out what the installation path is, and that code is copied from somewhere ages ago, and I have no idea how portable it is -- not really something I'm terribly happy with. Also, it doesn't solve looking for libraries, where we currently use `-rpath='$ORIGIN/../lib'`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260739481
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> I somewhat had the crazy hope there was a way to somehow overlay a filesystem > over / for the context of an app, and so that it would really be transparent. There are [a couple of options](https://github.com/probonopd/AppImageKit/issues/267) for that. But wouldn't it be the cleanest solution to solve it right in the source code from the beginning, by not using absolute paths? (How is it done for macOS)? > Effectively, it is exactly what you'd do if you target the macOS or Windows > platforms. > Unfortunately those are terribly painful, so it's not really a selling point > :) Well, the user's perspective is the opposite: With Windows, we can get your "original" software, directly from the developers, in the way the developers want it... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260735411
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
And so that there's no misunderstanding: * We **do appreciate 3rd party packages**, we thank people working on those. * But **I** will **not** support a Linux binary package bundling all dependencies myself. We would of course add a link to the website and such if someone asks us to do so for such a 3rd party package, but **I** will not want much part in the package itself. * Ultimately, we see ourselves as the upstream of the Geany **source code** as @eht16 said. * If we make Windows installers ourselves, it's because we know Windows users are unlikely to build the source code, and that there is no one else to do it for us. Believe me that Windows support altogether is a constant headache -- well, we manage pretty well at forgetting about it though :) * OSX packages are an initiative of one of our contributors. We are very glad he did that, but it still is a 3rd party package for which we simply provide some infrastructure, like hosting. By 3rd party here I mean that it's the work of someone, but not "the Geany project": he committed to do that package, but we didn't. We sure hope he'll keep doing it, and if he doesn't that someone interested will take over his work, but that package is not part of our "schedule". There are several reasons for that, and the more prominent are I guess manpower (we're a very small team), and personal motivation (someone would have to do it, and being volunteers we generally prefer to do things we like here :). All that to say that we'll provide technical support to whoever want to create packages, and be happy to see someone motivated. But we're unlikely to spend much effort doing the work itself at this time. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260731920
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> We recommend to _bundle everything that cannot be reasonably expected to be > part of each target system (default install) in a recent enough version_. > This means that if you build on an old enough build system, we can expect > something like glibc to "be part of each target system in a recent enough > version". However, if you build on a very recent build system, this may not > hold true, because your build artifacts will require a too new glibc version > which "cannot be reasonably expected to be part of each target system in a > recent enough version". So as always, it depends. Yes, I'm well aware about binary compatibility. > For practical reasons, I maintain a list of > [libraries](https://github.com/probonopd/AppImages/blob/master/excludelist) > and [debs](https://github.com/probonopd/AppImages/blob/master/excludedeblist) > that I currently assume to "be part of each target system". I see you list GTK+2 as a base library, so the bundle shouldn't require much libraries. > These lists are not perfect, however, so if you think that > `libpangoft2-1.0.so.0` should be added, you may well be right. PangoFT is a GTK2 dependency, so there's no reason to bundle it more. We don't depend on it directly either, only through GTK. > Effectively, it is exactly what you'd do if you target the macOS or Windows > platforms. Unfortunately those are terribly painful, so it's not really a selling point :) > AppImage is a self-mounting filesystem that simply executes what you put > inside. It's up to you what you put inside, […] Well, actually it seems far less "magical" than I hoped for, and a lot more like a mere unpack-and-run type of thing. For example, the need to patch everything under the installation directory to create relative installation directories. BTW, about that: * running `sed` on binary files requires care. Basically, you need to make sure that `LANG=C` (IIRC), otherwise it might not work and/or mess up the result. * running `sed` is hacky, but also might catch inappropriate things, in the string */usr* ever happens in something else than a path to a bundled data file/library. I somewhat had the crazy hope there was a way to somehow overlay a filesystem over `/` for the context of an app, and so that it would really be transparent. --- Anyway, it doesn't change much yet. At least for setting it up initially, we probably would need someone motivated -- and sorry, knowing exactly what he/she's doing. I'm not dismissing any effort here, and I definitely know that many things come with trial and error, I'm just saying that it'll likely take more time to end up with a "good" result. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260731250
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> A quick read on AppImage seems to suggest that it has the good taste of not > packing everything in, so that we probably could just distribute actual Geany > files in it, so that's good. We recommend to _bundle everything that cannot be reasonably expected to be part of each target system (default install) in a recent enough version_. This means that if you build on an old enough build system, we can expect something like glibc to "be part of each target system in a recent enough version". However, if you build on a very recent build system, this may not hold true, because your build artifacts will require a too new glibc version which "cannot be reasonably expected to be part of each target system in a recent enough version". So as always, it depends. For practical reasons, I maintain a list of [libraries](https://github.com/probonopd/AppImages/blob/master/excludelist) and [debs](https://github.com/probonopd/AppImages/blob/master/excludedeblist) that I currently assume to "be part of each target system". > Not sure about how automated it is, but if e.g. it can be created by a script > straight out of a make install DESTDIR=somewhere, it sounds easy enough. There are multiple ways to generate AppImages, among them: 1. **Convert existing binary packages**. This option might be the easiest if you already have up-to-date packages in place, ideally a ppa for trusty or earlier or a debian repository for oldstable. In this case, you can write a small `.yml` file and in many cases are done with the package to AppImage conversion. [See examples](https://github.com/probonopd/AppImages/tree/master/recipes/meta) **OR** 2. **Bundle your Travis CI builds as AppImages**. This option might be the easiest if you already have continuous builds on Travis CI in place. In this case, you can write a small scriptfile and in many cases are done with the AppImage generation. [See examples](https://github.com/search?utf8=%E2%9C%93&q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&ref=searchresults) > However, that wouldn't work with 32 and 64 bits out of the box, so the > question would be whether the AppImage is supposed to bundle 2 builds One AppImage per architecture. > it's unlikely we will really test this fairly continuously. If we were to > include this, we'd probably test it fairly at the start, but it's unlikely > we'll keep up with this over the next releases I think it should be OK do do explicit testing with various distros in the beginning and then leave it to people downloading the continuous builds to do the "testing". > I guess it depends on what AppImage actually is AppImage is a self-mounting filesystem that simply executes what you put inside. It's up to you what you put inside, but if you follow the general rule to "bundle everything that cannot be reasonably expected to be part of each target system in a recent enough version", then chances are that it will run on many target systems. In practice, building on Travis CI trusty means that the AppImage will run on 2014-ish distributions and later. > And additional concern might be 3rd party plugins, and especially > Geany-Plugins. Bundle all of them for the optimal out-of-the-box experience. > BTW, note that Geany is supposed to have binary relocation support (event > though virtually nobody tests it), so theoretically one could simply build > Geany with that enabled, and distribute a simple tarball. If you put the contents of this tarball inside an AppImage, then you gain the additional advantage that your users won't have to unpack a tarball, but can just run the image. > Gathering dependency versions over a number of distributions is possibly a > problem, think the recent libvte debacle where some distros shipped 2.90, > some 2.91 and some something else. Automating that is gonna be difficult. And > various plugins and webkit versions. And gtk2 or 3? And so on. In practice this is actually easy, run ldd on your app and bundle what it returns. Then delete libraries that we can reasonably expect to be part of each target system in a recent enough version from the bundle. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260708727
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
> libpangoft2 isn't a core lib to my understanding, so we can't just assume it > will be provided by most Linux distributions. IMO it can be considered to be. I'm not aware of any common distributions that don't come up packed with all GTK libraries, which depends on Pango, Cairo and whatnot. IMO, Geany itself has no non-"core" hard dependencies, the only open that might not be is libvte on GTK2, but it's runtime-optional. Plugins are a different story. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260707658
Re: [Github-comments] [geany/geany] Feature request: Please provide an AppImage for Geany (#1303)
@eht16 Not my distribution, all distributions that are not bleeding-edge take a while to update their Geany package. Even unofficial repositories that provide more up-to-date builds of Geany for most distros tend to lag behind. See for example the [`geany-dev/ppa`](https://launchpad.net/~geany-dev/+archive/ubuntu/ppa) for Ubuntu it still provides 1.27. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1303#issuecomment-260707447
