Hi,
At the moment Linux users are essentially left to wait until their respective distribution's repositories are updated and the new release of Geany is added. This process is so tedious, however, that for most non-bleeding edge distributions one has to wait months or years for this to happen (by which time usually an even newer release of Geany is out). So what I propose is that you's provide your own AppImages for Geany. AppImages, for those of you that are unaware, are a type of cross-distribution packaging format that need no special tools (like no special package manager to manage the packages) in order to be run. They merely need to be marked executable (with `chmod +x`) and run (with `./<AppImage>` where `<AppImage>` is the AppImage's filename, including its file extension). They are essentially self-mounting image files with an internal file system that contains all the files required to run the program they provide (which in this case would be Geany, of course).
I have created my own AppImage for Geany (which you can find [here](https://bintray.com/fusion809/AppImages/Geany#files)) but as you might notice it is presently out of date (version 1.28, versus the latest release of 1.29) as the Debian packages (and no this does not mean that this AppImage will only run on Debian systems, it will run on Arch Linux, Fedora, Gentoo, openSUSE, etc. as well) I built it from are presently out-of-date (although no doubt they will be updated soon). Plus my AppImage is built using Debian (Jessie) ingredients so it doesn't work on systems older than Jessie, while it is possible that you's could create a more flexible AppImage. You's could use your Travis CI artefacts instead of the Debian packages I use to build the AppImage, hence providing the very latest (more up-to-date than I could ever hope to provide) build of Geany. The way I uploaded my Geany AppImage to Bintray is using Travis CI, so they both easily integrated with one another. Alternatively you could upload the AppImages to the releases page of this GitHub repository.
If you need help with this I am more than willing to help, although I do believe @probonopd will be far more helpful than I, due to his superior knowledge of AppImages (after all he is the one that created the format).
Thanks for your time, Brenton
In general the Geany project has decided it will NOT provide packages itself for anything other than windows (and that only just). The Geany developers are not experts in any packaging system, and to become so, and to provide such packages would detract from the effort available for Geany development. Instead a wonderful set of contributors who are experts in packaging provide the packages for various systems.
If somebody wishes to provide so called portable packages, appimages, flatpacks, snaps or whatever and host them (eg on github), and most importantly MAINTAIN them, they are most welcome to, and Geany is happy to provide a link to them. But it is unlikely that the project itself will start providing such packages.
OK, although I just looked at your [`.travis.yml`](https://github.com/geany/geany/blob/master/.travis.yml) file and as it builds your source code on Ubuntu already I suspect it might be possible to turn that into an AppImage with minimal effort. @probonopd what do you think? If probonopd could explain how to do this to me I'd be willing to take care of this for yas. Like through a pull request. I'd love to eliminate the need of effort on the part of the Geany development team in order to get this done.
@fusion809 I am happy to support upstream projects that are willing to do upstream packaging, to provide a polished end-to-end user experience. But it doesn't seem to be the case that this project is willing to produce binaries for Linux.
'tis a shame. I've spent the past few hours trying to set up a Geany package in the Open Build Service for CentOS 5 and 6. That way I could use these packages to build a more up-to-date yet with older ingredients AppImage. Sadly that's failed pretty miserably. Now I'm gonna try Debian, but knowing how much more challenging Debian packaging is for me I suspect it won't be as successful as I am hoping for.
Well. IMO it depends on several factors, but the most important to me are: * Needs to be **reasonably automated**. Maintaining Windows and OSX packages proves to require work, and so we need people actually interested in them enough to keep them up. Unless we have someone that does this, it has to be automated reasonably well to not require manual changes in normal circumstances (like adding data files and the like). * **Not bundling 3rd party binaries**. We are part of what seems to be the odd upstream minority that actually understand distribution's concerns about bundling everything a gazillion times (security, size, effort duplication, take your pick).
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. 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.
From the AppImage Wiki I see:
- **Gather suitable binaries.** If the application has already been compiled, you can use existing binaries (for example, contained in .tar.gz, deb, or rpm archives). Note that the binaries must not be compiled on newer distributions than the ones you are targeting. In other words, if you are targeting Ubuntu 9.10, you should not use binaries compiled on Ubuntu 10.04. For upstream projects, it might be advantageous to compile special builds for use in AppImages, although this is not required.
That sounds reasonable.
- **Gather suitable binaries of all dependencies** that are not part of the base operating systems you are targeting. For example, if you are targeting Ubuntu, Fedora, and openSUSE, then you need to gather all libraries and other dependencies that your app requires to run that are not part of Ubuntu, Fedora, and openSUSE.
That too, as it suggests only non-standard deps should be packed (or then it'll depend on them being installed on the target machine). We have very few dependencies, so it's probably OK and we'd have nothing to pack.
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, only support one architecture, or rely on the 32 bit compatibility on 64 bits systems -- but then requires a lot more deps.
- **Test your AppImage** on all base operating systems you are targeting. This is an important step which you should not skip. Subtle differences in distributions make this a must. While it is possible in most cases to create AppImages that run on various distributions, this does not come automatically, but requires careful hand-tuning.
That sounds a lot more problematic I guess, because 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: we don't have the manpower nor enough motivation for this I'm afraid.
----
So… well I guess it depends on what AppImage actually is, and on the contributions from interested people. If it's a matter of running a script somewhere, it's probably fine. We could indeed even run it on TravisCI or something if needed. If it however requires some effort upon each release, I'd rather suggest following the OSX approach, that is being maintained by a "3rd party" (well, actually it's a regular contributor aside from that) and us only providing some infrastructure/visibility (repository under the Geany organization, links on the download pages, etc.).
And additional concern might be 3rd party plugins, and especially Geany-Plugins. It might be important to have a way to use those from whatever the bundle is, and it might raise some concerns, like should they be part of that bundle, or how to deal with their dependencies (as many have more complex dependencies that Geany).
--- 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. That doesn't apply to Geany-Plugins though.
@b4n, don't forget geany-plugins too, with its greater dependency requirements.
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.
Well my efforts to create a Debian package for 1.29 of geany and geany-plugins has failed, with the geany-plugins package. I moved to Launchpad, instead of using the Open Build Service. It failed with the error shown in [this build log](https://launchpadlibrarian.net/293528368/buildlog_ubuntu-trusty-amd64.geany-...). I've spent around 5 hours trying to build a suitable Geany and Geany Plugins 1.29 package to build an AppImage from and it truly is a pain. Then again, the only Linux package format I'm really adept at building are Arch Linux (i.e., pacman) packages. Why can't all package source files be as easy to write as PKGBUILDs...
It failed with the error shown in [this build log](https://launchpadlibrarian.net/293528368/buildlog_ubuntu-trusty-amd64.geany-...).
The error is pretty straightforward: GitChangebar plugin is force-enabled (`--enable-gitchangebar`), but one of its dependencies is missing:
Requested 'libgit2 >= 0.21' but version of libgit2 is 0.19.0
Either don't build this plugin, or use a recent enough version of libgit2.
Wondering why to invent the basics again: There is a src-rpm available for Fedora to fit needs to RH as well as there are deb for Debian could be used as basic.
@frlan Yeah the Debian package has much of its source files borrowed from another PPA. @b4n Fair enough, thanks, had such a long log I couldn't read it all, I searched for "error:" to try and narrow it down to the meat of it, but there were like 120 matches for that so... Building it on Xenial (with libgit2 0.24) also fails. One mo I'll that error too.
Disabling the gitchangebar plugin I get this error https://launchpadlibrarian.net/293530996/buildlog_ubuntu-trusty-amd64.geany-....
Hum that's odd…
config.status: error: cannot find input file: `po/Makefile.in.in'
Normally this file should be copied over by `glib-gettextize` I think. I see 2 possible reasons: * We depend on something newer than what you have, but don't advertize it (I doubt it, because AFAIK we didn't touch this area since 2010 or so) * The Debian package doesn't call our *autogen* script and doesn't call *glib-gettextize*, nor any other tool that would crate this file (*autopoint*, *intltool* or *gettextize* maybe), possibly because newer versions of some tool (*autoreconf* or *dh_autoreconf*) do that automatically now.
A quick and dirty solution could be calling our autogen script, not sure (beware that AFAIK *dh_autoreconf* does extra magic). Or calling the appropriate tool explicitly.
BTW, I see: ``` configure: WARNING: unrecognized options: --disable-maintainer-mode, --enable-geanylipsum, --enable-geanysendmail ```
*GeanyLipsum* and *GeanySendMail* have been renamed without the *Geany* prefix.
`--disable-maintainer-mode` I'm not sure, maybe it requires a newer Automake or something.
@b4n thanks for the help. I simply don't understand Debian rules files enough switch to using the autogen script. That's where PKGBUILDs are so much better, with it there's no special macros or commands (like `dh_autoreconf` just the standard set of commands one has access to at the command-line). I was hoping that this process would be as simple as copying existing Debian source files and modifying them slightly (like change config options like you mentioned in your last comment).
My latest effort failed https://launchpad.net/~brentonhorne/+archive/ubuntu/geany2/+build/11204415. I just tried to fix this by removing the install file for git-change (forgot to do that after disabling it).
Well, the *po/Makefile.in.in* part is gone. Would be better to know why it was there, and how it was fixed, but well.
Now it seems there's still reference to git-changebar plugin:
dh_install --list-missing -Xusr/share/doc/geany-plugins/ -X.la cp: cannot stat ‘debian/tmp/usr/share/geany-plugins/git-changebar’: No such file or directory dh_install: cp -a debian/tmp/usr/share/geany-plugins/git-changebar debian/geany-plugin-git-changebar//usr/share/geany-plugins/ returned exit code 1 ```
Now I'm getting https://launchpadlibrarian.net/293539813/buildlog_ubuntu-trusty-amd64.geany-.... I changed the `--enable-geanylipsum` part of my rules file to `--enable-lipsum`. But it seems like this plugin is being installed to a different location to where it was when this rules file was last edited by its original writer.
Yes, they have been renamed as I said, and their files too (like the DSO) ``` dh_install: geany-plugin-lipsum missing files (/usr/lib/*/geany/geanylipsum.so), aborting ```
Well I'll be .... it built correctly! Might have taken 8 hours of work but I finally Debian packages for geany and geany-plugins building for Trusty!
Oh happy day, I just created an AppImage from these Debian packages of mine. It seems to be working, but I'm gonna perform some more tests before I'll be able to say for certain.
Just published the AppImage with Travis CI on Bintray, so if anyone wants to try it out feel free https://bintray.com/fusion809/AppImages/Geany/1.29.glibc2.17.
@probonopd On my Ubuntu 16.10 VM I get this error:
```bash /bin/bash: ../lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/bash)
(geany:4134): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", /tmp/.mount_4Ad7s6/usr/bin/geany: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level ```
which is odd. My Debian (Jessie)-based Geany AppImage gave the same error when it didn't contain libpangoft2 files but this AppImage includes a file `/usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0`. Any ideas?
<not-necessarily-helpful-comment> Yeah, don't bundle all the libs, just Geany itself.
While I see certain advantages of approaches of AppImage (or Snappy or Flatpack or ZeroInstall or whatever), I have two remarks: - here is the wrong place to talk about, we provide the software, not the deployment - your initial argumentation seems wrong to me: you say because your distribution is slow(in your recognition) on package updates, you tell us to do your distribution's job. If your distribution is too slow or conservative on package updates for you, then either you should think about changing the distribution or talk to the package maintainer of Geany of your distribution. Again, we provide software, not deployment. At least not for non-Windows and non-MacOSX systems where just nothing like package managers and package maintainers exist, unfortunately.
Anyway, back to topic, I agree with @b4n: if there is someone (like you) who is willing to provide constantly properly built and tested AppImages for Geany, that would be a nice addition for all users.
Yeah, don't bundle all the libs, just Geany itself.
AppImages are designed to work out-of-the-box, without one needing to install any extra libs. libpangoft2 isn't a core lib to my understanding, so we can't just assume it will be provided by most Linux distributions.
@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.
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.
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...)
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.
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.
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.
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...
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'`.
@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 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.
@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 :)
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.
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.
@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.
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.
@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.
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/Rec.... As you can see I installed both `geany` and `geany-plugins` to the AppDir directory.
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. :)
Sure.
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.
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.
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`.
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.
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.
They're included because without GDK libraries I get an error on Fedora 24.
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.
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.
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.
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?
@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.
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.
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 maaaaany 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-<plugin>` 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.
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.
Is there a way to enable all plugins without specifying them each individually?
@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/deb....
Didn't you read what I said? I am using a CentOS 7 VM not Debian.
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.
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.
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 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.
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/`?
GeanyPy [requires PyGTK](https://github.com/geany/geany-plugins/blob/master/build/geanypy.m4#L5)
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.
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.ht...
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)
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 <AppImage>` to get the contents.
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.
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.
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.
Done 1.29.glibc2.15 was just published https://bintray.com/fusion809/AppImages/Geany#files. It's at 84 MB.
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.
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.
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.
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.
Oh and are libraries starting with `libicu` necessary?
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.
Yes, libicu is a direct dependency og WebKitGTK.
You're right libicu is a dependency of WebKitGTK, which I know as without it the web helper plugin isn't available.
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.g....
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.
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.
`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 ```
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)?
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.
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?
Arch is a bleeding edge distro, maybe its version needs gsettings that older distros don't.
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.
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.
But it probably only works on Fedora because you already have the packages installed, if you didn't, it would probably be broken too.
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.
Also tried it on openSUSE Tumbleweed and Debian 8 VMs without a problem. Both of which are fairly minimalistic too.
I can also confirm this plugin loads fine on Solus 1.2.1 and Sabayon Linux.
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* ```
Compression libraries (like `zlib` and `liblzma`) aren't required by Geany or its plugins are they?
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.
For the record, i've just stumbled on this snap "recipe" https://github.com/ubuntu/snappy-playpen/blob/geany/geany/snapcraft.yaml
It is for version 1.28, while my AppImage is for version 1.29 :).
Sure, i was just posting *for the record* :p
Just wanted to say that I really like the constructive collaboration here. Thank you @fusion809 and everyone and keep up the good work!
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 ?
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?
@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.
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.
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.
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.
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.
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.
@elextr @probonopd I would welcome if somebody steps up to provide an AppImage (based on releases) under the Geany umbrella.
@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...
An AppImage would be cool, @ecmu I starred your repo. :) Other people should too ;)
@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
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
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?
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).
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.
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.
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.
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...
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
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.
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.
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.
New year, new luck :D.
https://github.com/geany/www.geany.org/pull/42 will add the AppImage from @ecmu to the Third Party packages list on the website. Feel free to comment in the PR, also to extend/improve the steps to get it running.
github-comments@lists.geany.org