Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Cheers Lex
On Wed, 17 Nov 2010 13:40:42 +1100 Lex Trotman elextr@gmail.com wrote:
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Unfortunately I don't know that a shell login argument is portable. I think -l is specific to bash, but even --login doesn't work for dash (the default /bin/sh on Ubuntu IIRC).
We could have string prefs for what arguments to pass to build/execute, empty by default.
Nick
On 24 November 2010 03:01, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 17 Nov 2010 13:40:42 +1100 Lex Trotman elextr@gmail.com wrote:
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Unfortunately I don't know that a shell login argument is portable. I think -l is specific to bash, but even --login doesn't work for dash (the default /bin/sh on Ubuntu IIRC).
Patch actually developed and tested on Ubuntu.
We could have string prefs for what arguments to pass to build/execute, empty by default.
Maybe it should be the whole shell command?? eg sh -l (or not -l as appropriate)
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 24 Nov 2010 08:36:18 +1100 Lex Trotman elextr@gmail.com wrote:
Unfortunately I don't know that a shell login argument is portable. I think -l is specific to bash, but even --login doesn't work for dash (the default /bin/sh on Ubuntu IIRC).
Patch actually developed and tested on Ubuntu.
Maybe yours is Bash then.
A while ago I saw: https://wiki.ubuntu.com/DashAsBinSh
And my dash-0.5.4-2.fc8 doesn't seem to have a login argument.
Anyway, I saw the xprofile messages so I'll leave this.
Nick
On 24 November 2010 23:49, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 24 Nov 2010 08:36:18 +1100 Lex Trotman elextr@gmail.com wrote:
Unfortunately I don't know that a shell login argument is portable. I think -l is specific to bash, but even --login doesn't work for dash (the default /bin/sh on Ubuntu IIRC).
Patch actually developed and tested on Ubuntu.
Maybe yours is Bash then.
No bin/sh -> dash
A while ago I saw: https://wiki.ubuntu.com/DashAsBinSh
And my dash-0.5.4-2.fc8 doesn't seem to have a login argument.
Correct IAW the POSIX spec.
Yet the patch worked on my system??
Anyway, I saw the xprofile messages so I'll leave this.
Yes, if it isn't broke, lets not fix it :-)
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 25 Nov 2010 11:24:07 +1100 Lex Trotman elextr@gmail.com wrote:
Unfortunately I don't know that a shell login argument is portable. I think -l is specific to bash, but even --login doesn't work for dash (the default /bin/sh on Ubuntu IIRC).
Patch actually developed and tested on Ubuntu.
Maybe yours is Bash then.
No bin/sh -> dash
A while ago I saw: https://wiki.ubuntu.com/DashAsBinSh
And my dash-0.5.4-2.fc8 doesn't seem to have a login argument.
Correct IAW the POSIX spec.
Yet the patch worked on my system??
Well either your dash supports -l or the shell that gets run isn't dash. Anyway, -l is non-standard and there could be systems it wouldn't work on.
Nick
On Wed, 17 Nov 2010 13:40:42 +1100 Lex Trotman elextr@gmail.com wrote:
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
According to: http://www.mkssoftware.com/docs/man1/sh.1.asp#Options_and_Invocation
~/.bashrc is run even for a non-login shell ~/.profile is run only for login shells
Maybe that's why we experience different behaviour - I use bashrc not profile. Could be that the Window Manager isn't relevant?
Nick
On 24 November 2010 03:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 17 Nov 2010 13:40:42 +1100 Lex Trotman elextr@gmail.com wrote:
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
According to: http://www.mkssoftware.com/docs/man1/sh.1.asp#Options_and_Invocation
~/.bashrc is run even for a non-login shell ~/.profile is run only for login shells
Maybe that's why we experience different behaviour - I use bashrc not profile. Could be that the Window Manager isn't relevant?
No.
1. the actual environment variables are set in .bashrc & .profile just calls that
2. Your reference above isn't clear that a non-interactive shell invoked as sh only loads the BASH_ENV file and none of the others but official Gnu docs are, see section 6.2 in:
http://www.gnu.org/software/bash/manual/bashref.html#Invoking-Bash
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
Perhaps what could be done would be to allow build environment variables to be customized in Geany?
On 24 November 2010 13:15, Chow Loong Jin hyperair@gmail.com wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose.
@Chow,
cp .profile .xprofile
fixed it, thanks.
@Nick forget the patch.
I don't think a login
shell or interactive shell should be used for this purpose though.
Agree it shouldn't be interactive, after all we don't want prompts everywhere.
Perhaps what could be done would be to allow build environment variables to be customized in Geany?
No, commands started in Geany should work exactly as they do from the command line, manually setting up the environment in two places is too error prone (especially for me :-).
Cheers Lex
-- Kind regards, Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wednesday 24,November,2010 11:27 AM, Lex Trotman wrote:
On 24 November 2010 13:15, Chow Loong Jin hyperair@gmail.com wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose.
@Chow,
cp .profile .xprofile
fixed it, thanks.
@Nick forget the patch.
I don't think a login
shell or interactive shell should be used for this purpose though.
Agree it shouldn't be interactive, after all we don't want prompts everywhere.
Perhaps what could be done would be to allow build environment variables to be customized in Geany?
No, commands started in Geany should work exactly as they do from the command line, manually setting up the environment in two places is too error prone (especially for me :-).
Then you probably want to do something like echo '. $HOME/profile' > ~/.xprofile to eliminate redundancy. :-)
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Lex, above you said yourself, other window managers (I assume other than metacity or compiz), work ok. So, that's a pretty good argument to *not* fix it in Geany.
And yes, I noticed you already solved the problem for your system :).
Regards, Enrico
2010/11/25 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Thats very harsh for the poor Ubuntu users who didn't cause the problem themselves, especially as it causes significant problems eg I couldn't compile Geany with any CFLAGS, no wonder I kept missing warnings :-(
But since Chow fixed the problem I forgive you :-)
Cheers Lex
Lex, above you said yourself, other window managers (I assume other than metacity or compiz), work ok. So, that's a pretty good argument to *not* fix it in Geany.
And yes, I noticed you already solved the problem for your system :).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 25 Nov 2010 10:36:51 +1100, Lex wrote:
2010/11/25 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Thats very harsh for the poor Ubuntu users who didn't cause the problem themselves, especially as it causes significant problems eg I
True. Still I see this as an Ubuntu problem as they (Ubuntu/Gnome/whatever developers, not users) messed it up. Of course, the end user sitting in front of the box and just wishing to simply work, doesn't care who is at fault if it doesn't work.
But since Chow fixed the problem I forgive you :-)
Uh, lucky me. Thank you.
:)
Regards, Enrico
On Thursday 25,November,2010 03:06 AM, Enrico Tröger wrote:
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Lex, above you said yourself, other window managers (I assume other than metacity or compiz), work ok. So, that's a pretty good argument to *not* fix it in Geany.
And yes, I noticed you already solved the problem for your system :).
This isn't a window manager problem, it's a session manager problem. Also, sourcing .bash_login/.profile on GUI login is retarded behaviour, especially when you have something like screen autolaunch + auto-logout after screen detaches going on inside that. I had a hard time trying to figure out why my session on my university lab's Fedora machines wouldn't log into any graphical session due to this.
On 25 November 2010 16:09, Chow Loong Jin hyperair@gmail.com wrote:
On Thursday 25,November,2010 03:06 AM, Enrico Tröger wrote:
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Lex, above you said yourself, other window managers (I assume other than metacity or compiz), work ok. So, that's a pretty good argument to *not* fix it in Geany.
And yes, I noticed you already solved the problem for your system :).
This isn't a window manager problem, it's a session manager problem. Also, sourcing .bash_login/.profile on GUI login is retarded behaviour,
Maybe, but how then are environment variables supposed to be set? Remember in this case they are for non-GUI applications invoked from the GUI.
Cheers Lex
especially
when you have something like screen autolaunch + auto-logout after screen detaches going on inside that. I had a hard time trying to figure out why my session on my university lab's Fedora machines wouldn't log into any graphical session due to this.
-- Kind regards, Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thursday 25,November,2010 03:43 PM, Lex Trotman wrote:
On 25 November 2010 16:09, Chow Loong Jin hyperair@gmail.com wrote:
On Thursday 25,November,2010 03:06 AM, Enrico Tröger wrote:
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Lex, above you said yourself, other window managers (I assume other than metacity or compiz), work ok. So, that's a pretty good argument to *not* fix it in Geany.
And yes, I noticed you already solved the problem for your system :).
This isn't a window manager problem, it's a session manager problem. Also, sourcing .bash_login/.profile on GUI login is retarded behaviour,
Maybe, but how then are environment variables supposed to be set? Remember in this case they are for non-GUI applications invoked from the GUI.
Interactive shells will have their own dot files like .zshrc and .bashrc. Non-interactive shells will inherit the environment from their parents, and their parents will probably inherit it from the session manager, which will source ~/.xprofile.
In order to have a single point of configuration, I'd do something like:- cat > ~/.env <<EOF export CFLAGS=blah export LDFLAGS=blah export ANYTHINGELSE=blah EOF echo . ~/.env >> ~/.$shellrc echo . ~/.env >> ~/.xprofile
Then I'd just configure my environment variables in ~/.env and be happy.
I don't really see this whole issue as a problem, really. Just ~/.xprofile not being widely known. A quick google search shows that ~/.xprofile appears to be pretty standard across distributions, too, so Enrico, this behaviour isn't broken or anything, it's pretty much standard. If your distribution doesn't support ~/.xprofile, then your distribution's broken.
On the other hand, I mentioned providing a configuration interface for setting build environment variables because I thought it might be useful if you need different flags for different projects, rather than all of them using the same set of flags whereby you can stuff them in some dot file.
On 26 November 2010 07:44, Chow Loong Jin hyperair@gmail.com wrote:
On Thursday 25,November,2010 03:43 PM, Lex Trotman wrote:
On 25 November 2010 16:09, Chow Loong Jin hyperair@gmail.com wrote:
On Thursday 25,November,2010 03:06 AM, Enrico Tröger wrote:
On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
Hi,
When Geany is started from the Gnome menu it doesn't get environment variables set in .profile, .bashrc etc. Other window managers seem ok.
This means that builds don't see CFLAGS, python executes don't see PYTHONPATH etc :-(
Although builds and executes run in shells, a non-interactive shell does not load any startup files.
The attached patch adds the option (-l) to run the build and execute shells as login shells which will load startup files.
Two hidden prefs build_in_login_shell and exec_in_login_shell allow you to disable this for builds or executes respectively if running your startup scripts causes some problem.
Hi,
I actually believe that on some distros .bashrc/.profile is sourced by default on gdm, and on others, .xprofile is used for this purpose. I don't think a login shell or interactive shell should be used for this purpose though.
I agree completely. If Ubuntu messed up with their system, it's their problem. Why should we fix Ubuntu's or Gnome's mistakes in Geany? In other, less harsh words, I think an applicaton should not fix the problems in the outer environment.
Lex, above you said yourself, other window managers (I assume other than metacity or compiz), work ok. So, that's a pretty good argument to *not* fix it in Geany.
And yes, I noticed you already solved the problem for your system :).
This isn't a window manager problem, it's a session manager problem. Also, sourcing .bash_login/.profile on GUI login is retarded behaviour,
Maybe, but how then are environment variables supposed to be set? Remember in this case they are for non-GUI applications invoked from the GUI.
Interactive shells will have their own dot files like .zshrc and .bashrc. Non-interactive shells will inherit the environment from their parents, and their parents will probably inherit it from the session manager, which will source ~/.xprofile.
In order to have a single point of configuration, I'd do something like:- cat > ~/.env <<EOF export CFLAGS=blah export LDFLAGS=blah export ANYTHINGELSE=blah EOF echo . ~/.env >> ~/.$shellrc echo . ~/.env >> ~/.xprofile
Then I'd just configure my environment variables in ~/.env and be happy.
I don't really see this whole issue as a problem, really. Just ~/.xprofile not being widely known.
Which is actually the problem!! Its not documented. Should be in man xsession where ~/.xsession etc are documented.
A quick google search shows that ~/.xprofile appears to be
pretty standard across distributions, too, so Enrico, this behaviour isn't broken or anything, it's pretty much standard. If your distribution doesn't support ~/.xprofile, then your distribution's broken.
It can't be considered standard until documented somewhere that makes it a promise by the system, to date its just common, not standard.
On the other hand, I mentioned providing a configuration interface for setting build environment variables because I thought it might be useful if you need different flags for different projects, rather than all of them using the same set of flags whereby you can stuff them in some dot file.
True, but in practice how often would it be used.
The things different projects need different (eg optimisation/debug) would/should be set where make will notice them change rather than in an environment variable. That way they "should" trigger make to re-compile. I don't really advocate using CFLAGS to pass options to compilers since changes won't cause make (or any other builder that I know of) to re-run.
The thing that actually caused problems was PYTHONPATH since the build script couldn't find its library, and PATH would likely be another problem for executes. But these can safely be shared by all.
Cheers Lex
-- Kind regards, Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel