Package: geany-plugins / 1.24+dfsg-5
Metadata
Package | Version | Patches format |
---|---|---|
geany-plugins | 1.24+dfsg-5 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
debian doc locations.patch | (download) |
commander/src/commander-plugin.c |
2 1 + 1 - 0 ! |
load help files from debian's locations |
geanypy link gmodule.patch | (download) |
build/geanypy.m4 |
1 1 + 0 - 0 ! |
[patch] geanypy: add missing linking against gmodule |
hurd.patch | (download) |
scope/src/conterm.c |
5 4 + 1 - 0 ! |
scope: build properly on gnu/hurd The scope plugin currently does not build on GNU/Hurd. These patches fix the issue by properly detecting BSD flavours (and not misdetecting GNU/Hurd as one) and defining PATH_MAX as GNU/Hurd has no such limitation. |
debugger_fix_GCond_usage.patch | (download) |
debugger/src/dconfig.c |
12 4 + 8 - 0 ! |
[patch] debugger: fix gcond usage g_cond_wait() and the likes unlock the passed in mutex during the wait and re-lock it before returning. However, the code here used to pass in an unlocked mutex. This used to work because GLib threading implementation was tolerant and allowed unlocking an unlocked mutex, but GLib 2.42 has a new and less tolerant implementation that would abort in such situation. Fix this by properly locking the passed in mutex. The implementation here also removes the second mutex only used for the condition as the one used to protect the loop body can very well be used and actually makes sense as they protect the same thing. Doing so requires to properly wait for the thread to quit before destroying the mutex, but this probably should be done anyways to avoid forcefully killing the thread when the application quits. |
debugger_fix_internal_state.patch | (download) |
debugger/src/envtree.c |
6 6 + 0 - 0 ! |
[patch] debugger: fix internal envtree state after plugin reload As the module is resident, the global variables won't get reinitialized automatically when the plugin is reloaded, so reinitialize them explicitly. This is especially important for the `empty_row` variable as not re-initializing it will lead to a double-free, and possibly a crash. |
debugger_fix_crash_with_gdb_7.7.patch | (download) |
debugger/src/dbm_gdb.c |
4 2 + 2 - 0 ! |
[patch] debugger: fix crash with gdb 7.7 GDB 7.7 doesn't understand `&` as an argument to `-exec-run`. Moreover, the code handling errors from GDB has an issue with this error and leads to a crash. Closes https://sourceforge.net/p/geany-plugins/bugs/112/ |