### We are looking for a new maintainer for the Windows builds of Geany
**You want to:** - continue using Geany (or start doing so) - maintain the Windows builds of Geany - support the Geany developers on creating releases - have fun with Geany's codebase, MSYS2 and Microsoft Windows and all the problems these create
**Your benefits:** - fame and glory - happy users of Geany on Windows
More seriously, while Geany is developed mostly on Linux and probably most of the user base is using Linux as well, there are also some Windows users. In the past, the Windows builds were maintained by me (eht16) but I cannot continue because I used a Windows 7 VM but Windows 7 is no longer supported by MSYS2 which the builds are based on. I will not upgrade to or use any newer version of the operating system for various reasons, so we are looking for someone who wants to take over.
Feel free to ask questions and comment here in this issue.
I may be able to help as I already build on msys2 for my hobby project https://github.com/giuspen/cherrytree via the script https://github.com/giuspen/cherrytree/blob/master/scripts/msys2_prepare_stan... ( and package via inno setup script https://github.com/giuspen/cherrytree/blob/master/scripts/cherrytree.iss )
Hi @giuspen,
that would be great, thank you!
Some random thoughts about the setup and how to get you started: - a good start could be to setup everything on your Windows machine, there is a how to at https://wiki.geany.org/howtos/win32/msys2, have a look and feel free to improve/rewrite it - the CI setup is splitted in: - the Docker base image which contains Pacman, the MSYS2 environment for cross-compilation based on Debian packages and Wine for executing Windows binaries, the sources can be found at https://github.com/geany/infrastructure/tree/master/builders also with a little documentation - the Geany part: https://github.com/geany/geany/blob/master/scripts/ci_mingw64_geany.sh and https://github.com/geany/geany/blob/master/.github/workflows/build.yml - the Geany-Plugins part: https://github.com/geany/geany-plugins/blob/master/build/ci_mingw64_geany_pl... and https://github.com/geany/geany-plugins/blob/master/.github/workflows/build.y... - we use NSIS for generating installers (not INNO setup) but I think the idea is similar behind the installers (https://github.com/geany/geany/blob/master/geany.nsi.in and https://github.com/geany/geany-plugins/blob/master/build/geany-plugins.nsi) - I just created PRs for creating the installers as 64bit binaries and so removing the Wine 32bit environment - these could be a good start to get more familiar with the CI setup - https://github.com/geany/infrastructure/pull/14 - https://github.com/geany/geany/pull/4194 - https://github.com/geany/geany-plugins/pull/1402 - the current CI setup can be improved certainly, there is a a native MSYS2 Github action which could be used instead of cross-compilation and probably other things, feel free if you like - in the past, I created Windows releases natively on Windows 7 (no cross-compilation). I should be possible to create them also from the CI, I started to prepare this but did not finish yet. We could either go this way or you create them also natively on Windows, as you like.
Please ask any questions as they arrive, here or via mail or Matrix chat.
I have been interested in building Geany in a non-docker MSYS2 environment to support debugging.
I am willing to test nightly releases or CI artifacts (such as I am using daily). I am interested in helping to solve some errors unique to the Windows environment. And possible working with some unsupported, or missing plugins.
I may not be able to commit significant time to the project due to stamina and health issue, but, since I use Geany so much, would like to contribute what I can
Hallo @eht16 I have been using Geany for almost 20 years now on both Linux and Windows, I'm happy to give something back. I'll follow the links you posted and get back for questions in the next days. Maybe better I will follow up here so that others interested such as @djhenderson can follow too.
So I followed https://wiki.geany.org/howtos/win32/msys2 and built successfully from the cloned git repos geany and then geany-plugins and installed both. Note that I had a build error on geany-plugins complaining about missing files which were in fact present, that error was resolved with the following diff ``` diff --git a/geanygendoc/docs/Makefile.am b/geanygendoc/docs/Makefile.am index f3975b69..bde0f83a 100644 --- a/geanygendoc/docs/Makefile.am +++ b/geanygendoc/docs/Makefile.am @@ -15,6 +15,6 @@ dist_pluginhtmldoc_DATA = \ if BUILD_RST manual.html: manual.rst manual.css html4css1.css $(AM_V_GEN) $(RST2HTML) -d --strict \ - --stylesheet-path $(abs_srcdir)/html4css1.css,$(abs_srcdir)/manual.css \ + --stylesheet-path $(srcdir)/html4css1.css,$(srcdir)/manual.css \ $(srcdir)/manual.rst $@ endif BUILD_RST ``` After installing I did run successfully `/c/geany/bin/geany` but under Tools--Plugin Manager I got empty plugins. I will continue with the wiki trying to create the installers and I will investigate further on why the plugins are not in the plugin manager even though installed.
After installing I did run successfully /c/geany/bin/geany but under Tools--Plugin Manager I got empty plugins.
I will continue with the wiki trying to create the installers and I will investigate further on why the plugins are not in the plugin manager even though installed.
I remember having the same problem in https://github.com/geany/geany/issues/4082#issuecomment-2509035605 but I also didn't find a way to manage to see them (but I didn't spend much time on it).
I never ran Geany from within the MSYS2 environment but copied `geany.exe`, `libgeany.dll` and if necessary plugin DLLs into an existing normal Geany installation and executed it "natively". This worked well except for debugging.
If you want to go the MSYS2 way, maybe a look in Help->Debug Messages might help what Geany thinks what is its "System plugin path" and what is logged when the Plugin Manager dialog tries to load the plugin DLLs.
Yes that's how I run cherrytree in windows ( https://github.com/giuspen/cherrytree/blob/master/BUILDING.md#building-cherr... ) I will try to add support for running Geany straight from msys2 too as I get to know a bit more how things work. For now anyway I will simply proceed to get to know your current way.
关于Windows平台geany 2.0版本问题的反馈。我经常在使用Win10和Win11时遇到它。当将.py文件复制到其他位置时，编辑后无法保存，保存时会出现错误消息。它必须另存为。我希望下一个版本可以修复它。 Feedback on a problem with the Windows platform's geany 2.0 version. I often encounter it when using both Win10 and Win11. When a. py file is copied to another location, it cannot be saved after editing, and there will be an error message when saving. It must be saved as. I hope the next version can fix it.
@kaiyongwangphoenix Please open a separate issue - this has nothing to do with looking for a new maintainer for Windows builds. Sounds more like https://github.com/geany/geany/issues/2748.
After installing I did run successfully /c/geany/bin/geany but under Tools--Plugin Manager I got empty plugins. I will continue with the wiki trying to create the installers and I will investigate further on why the plugins are not in the plugin manager even though installed.
I remember having the same problem in [#4082 (comment)](https://github.com/geany/geany/issues/4082#issuecomment-2509035605) but I also didn't find a way to manage to see them (but I didn't spend much time on it).
@techee I found out that the reason was that the .dll were not actually built.
I updated the instructions, basically before the configure you have to run an export: ``` export lt_cv_deplibs_check_method=${lt_cv_deplibs_check_method='pass_all'} ./configure --prefix=/c/geany make -j make install ```
@techee I found out that the reason was that the .dll were not actually built.
Great, thanks. I haven't had time to test myself but I believe you :-)
I maybe will do something very very interesting here
Hello @eht16 I have reached the point of creating the installers but I am in the need of key/certificate in order to sign (`codesign_key.pem`, `codesign.pem`). Should I get a unique set myself? I haven't done this before, can you point me to where you did get yours? ``` Execute command: osslsigncode sign -verbose -certs C:\msys64\home\PenoneG/geany_build/codesign.pem -key C:\msys64\home\PenoneG/geany_build/codesign_key.pem -n Geany Binary -i https://www.geany.org -ts https://zeitstempel.dfn.de/ -h sha512 -in C:\msys64\home\PenoneG/geany_build/release/geany/bin/geany.exe -out C:\msys64\home\PenoneG/geany_build/release/geany/bin/geany.exe-signed Failed to read certificate file: C:\msys64\home\PenoneG/geany_build/codesign.pem Failed to read key or certificates 68100000:error:80000002:system library:BIO_new_file:No such file or directory:../openssl-3.4.0/crypto/bio/bss_file.c:67:calling fopen(C:\msys64\home\PenoneG/geany_build/codesign_key.pem, rb) 68100000:error:10000080:BIO routines:BIO_new_file:no such file:../openssl-3.4.0/crypto/bio/bss_file.c:75: 68100000:error:80000002:system library:BIO_new_file:No such file or directory:../openssl-3.4.0/crypto/bio/bss_file.c:67:calling fopen(C:\msys64\home\PenoneG/geany_build/codesign.pem, rb) 68100000:error:10000080:BIO routines:BIO_new_file:no such file:../openssl-3.4.0/crypto/bio/bss_file.c:75: Failed Traceback (most recent call last): File "C:/msys64/home/PenoneG/geany-release.py", line 132, in <module> make_release() File "C:/msys64/home/PenoneG/geany-release.py", line 111, in make_release sign_files(*binary_files) File "C:/msys64/home/PenoneG/geany-release.py", line 81, in sign_files run_command( File "C:/msys64/home/PenoneG/geany-release.py", line 41, in run_command check_call(cmd, **kwargs) File "C:/msys64/mingw64/lib/python3.12/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '('osslsigncode', 'sign', '-verbose', '-certs', 'C:\msys64\home\PenoneG/geany_build/codesign.pem', '-key', 'C:\msys64\home\PenoneG/geany_build/codesign_key.pem', '-n', 'Geany Binary', '-i', 'https://www.geany.org', '-ts', 'https://zeitstempel.dfn.de/', '-h', 'sha512', '-in', 'C:\msys64\home\PenoneG/geany_build/release/geany/bin/geany.exe', '-out', 'C:\msys64\home\PenoneG/geany_build/release/geany/bin/geany.exe-signed')' returned non-zero exit status 4294967295.
```
For now I changed sign_files to skip if the SIGN_CERTIFICATE_KEY is missing. There was already an instruction to do that but with a bug as `isfile()` was missing. Wouldn't be better to version geany-release.py and geany-plugins-release.py in the respective git repos rather than hosting in the wiki? ``` def sign_files(*paths): if not isfile(SIGN_CERTIFICATE_KEY): print('Skipped signing {} as {} not found'.format(paths, SIGN_CERTIFICATE_KEY)) return for item in paths: ... ```
I successfully generated the installer with a few changes to the original script linked from the wiki: [geany-release.zip](https://github.com/user-attachments/files/18629185/geany-release.zip)
Hello [@eht16](https://github.com/eht16) I have reached the point of creating the installers
Hooray! Nice to hear.
but I am in the need of key/certificate in order to sign (`codesign_key.pem`, `codesign.pem`). Should I get a unique set myself? I haven't done this before, can you point me to where you did get yours?
The certificate I used was from https://www.cacert.org. I registered there in 2006 or so and had to meet to couple of people to verify me and so to be able to get a certificate issued. I don't know if the process is still that complicated.
In the end it's probably not worth at all. The root certificate of cacert.org is not included in the common OS and browser bundles and so a proper verification can be made only after installing the root certificate of cacert.org manually by the user. I doubt anyone really did this in the past. I only knew a single user who wished those digital signatures and I actually asked here six months ago if this is still the case but she didn't answer.
Furthermore, even if you had a certificate, if we will eventually create release installers in the pipeline, you had to upload the private key of the certificate to Github or somewhere else where the CI job can access it. This is something I would never do because you never know what Github does with that key. Additionally, signing an automatically created binary on a third party system (Github runner) with a *personalised* certificate doesn't give much security as you personally cannot verify its complete integrity anyway and in the worst case you personally would be responsible for any malicious code, corruption or whatever, just because it is signed with your certificate.
So, I suggest we do not sign the binaries any longer.
For now I changed sign_files to skip if the SIGN_CERTIFICATE_KEY is missing. There was already an instruction to do that but with a bug as `isfile()` was
Sorry for the bug and the trouble it might caused :(.
missing. Wouldn't be better to version geany-release.py and geany-plugins-release.py in the respective git repos rather than hosting in the wiki?
Fine by me. It might fit in the `scripts` directory in Geany and in the `build` directory in G-P.
Clear, thanks @eht16 I will submit a PR. Still having some issues with the installer for geany-plugins as it doesn't find the languages ` File /r "${GEANY_PLUGINS_RELEASE_DIR}\share\locale*"` Will update here when I find the reason.
Ok I got also the installer for the plugins working. I will submit a PR for the changes I had to apply. [geany-plugins-release.zip](https://github.com/user-attachments/files/18629729/geany-plugins-release.zip)
Ok I got also the installer for the plugins working.
Yay. What I usually did to verify the created installers was a bit manual testing: - uninstall previously Geany and Geany-Plugins (if it was installed) - install Geany from installer - start installed Geany and check Help->Debug Messages for warnings, errors, "file not found" messages or anything else which might look suspicious (sorry, I don't have a better description, it was to get sure everything what Geany expects was installed) - open Help->Help to see the manual will be opened in a browser from the local installation - quit Geany - install Geany-Plugins from installer - start Geany - open Plugin Manager dialog - check Help->Debug Messages if there are any plugin loading errors - load a few plugins, especially those with dependencies or additional files installed: SpellCheck, GitChangeBar, GeanyLua, UpdateChecker - check for error messages in Help->Debug Messages - quit Geany - uninstall Geany-Plugins - install Geany-Plugins again but *not* in the Geany prefix but into a different path - uninstall Geany-Plugins again and check that there are not much left overs in the installation path (I think share/licenses and share/locale are ok otherwise we would have to keep track on each installed single file) - the idea here was that at least the majority of files in bin/ and etc/ is removed
The last check is also done in the CI (https://github.com/geany/geany-plugins/blob/master/build/ci_mingw64_geany_pl...) and I usually checked this before releases as due to dependency updates it is common that the filenames of libraries change and it's tedious to do this more than necessary :). If there are any left overs, then the list in https://github.com/geany/geany-plugins/blob/master/build/geany-plugins.nsi#L... can be updated.
This method can certainly be scrutinised. My rationale was that it is nice when an uninstaller cleans (almost) anything which it installed before. Unfortunately, we cannot just delete whole directories in most cases as usually G-P are installed in the same path as Geany and so we would potentially also delete files installed by Geany itself.
github-comments@lists.geany.org