@swattor Can you tell something about your system?

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158063152

On 2015-11-19 3:50 AM, swattor wrote:

When compiling release geany-1.26 I encounter the following error:

spawn.c: In function 'spawn_async_with_pipes': spawn.c:625: error: 'G_SPAWN_ERROR_TOO_BIG' undeclared (first use in this function) spawn.c:625: error: (Each undeclared identifier is reported only once spawn.c:625: error: for each function it appears in.) make[2]: *** [libgeany_la-spawn.lo] Error 1

What if you change that symbol to `G_SPAWN_ERROR_2BIG`? The alias shown in your error message was added in March 2012, so maybe your GLib is too old.

Cheers, Matthew Brush

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158091420

A little of both. The missing symbol was added in 2012, so probably nobody but a centos user would notice :) But also GLib doesn't always document when stuff was added to their API, so if the symbol is newer than our lowest supported GLib version, probably the developer didn't even notice since it's not mentioned in the docs what version added that symbol.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158262999

On 20 November 2015 at 12:44, Matthew Brush notifications@github.com wrote:

@zhekov https://github.com/zhekov is that symbol too new?

​To save him looking, yes its too new, ​

​we test for glib 2.28 and its not in that.

Should be able to #ifndef #define it in compat easily though.

Cheers Lex

PS TFL to look what version it *did* come in ​

— Reply to this email directly or view it on GitHub https://github.com/geany/geany/issues/764#issuecomment-158263091.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158266354

On 20 November 2015 at 19:42, swattor notifications@github.com wrote:

Looks like I have glib 1.2.10

​Ahhh, it will have to be above (or equal) 2.28​ or Geany would not have configured.

​Cheers Lex​

— Reply to this email directly or view it on GitHub https://github.com/geany/geany/issues/764#issuecomment-158338312.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158352165

Oh, sorry - yes my bad. I do in fact have 2.28.8

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158359498

Must be replaced with G_SPAWN_ERROR_2BIG. That's the symbol in 2.28, and it's still supported in the current 2.47, unless G_DISABLE_DEPRECATED is specifically defined. There should be no need to check the glib version.

So, do I open a PR, or somebody will fix it?

(It would be nice if we switch Geany to protected branches. Currently, creating a PR is too clumsy.)

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158468191

@zhekov you can also use Github's tool "hub", then it's just:

```bash $ git checkout -b whatever-topic # hack hack hack $ git pull-request ```

Though I think we should protect the master branch against force pushes (even if it doesn't solve the problem of difficulty making pull requests at all).

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158566981

@elextr

Te-he, I have no Linux on the new machine, and can't test it... If I create the PR as you describe, will the standard compilation tests will be run on it?

@codebrainz

My impression was that these new "protected branches" are to make some branches (master, releases) writable to the few chosen, and let anyone else create their own branches directly inside geany/geany, simplifying the PR-s. But I haven't read about this in detail...

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158667853

@zhekov yes PRs made with the github editor are tested by Travis. Though that won't help in this case since the version of glib it uses is probably too new for the bug to show.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-158686323

As I read the protected branches they don't stop you pushing to the master branch, they just put a few requirements on that.

You still need repo rights to create the branches in the repo. And that means you have push rights to the master branch (you just have to meet the requirements). So it would only be more convenient for those who already have access.

Note that some of your steps below are once only, like forking on github and some should be once only or at least rare like cloning locally.

The steps really are like b4n described.

Cheers Lex

On 24 November 2015 at 04:26, zhekov notifications@github.com wrote:

What I do know as "creating a PR" is (generic terminology, not git)

Open GitHub and fork Geany into myname. Create a branch on github myname. Fetch geany myname from github. Switch to branch and edit it. Commit it. Open github and create PR.

The details may vary a bit, for example a subsequent fork may be "ff only", but generally it should be something like that. Now we have:

1. geany master
2. myname master on gitgub
3. myname branch on github
4. myname master on the local machine
5. myname branch on the local machine

I cannot help but think that a total of 5 Geany copies are a bit too much for a simple PR. And copies 2-5 are not really related to geany master - "origin master" means myname master. Huh...

If I understood the protected branches correctly, the scheme will be:

1. geany master - protected, writable to leading devs only.
2. geany mybranch on github - writable to myname as creator.
3. geany mybranch on the local machine.

Simpler, real origin, and GitHub PR-s are be used because they are convenient, not required. Though seeing all branches may be a bit too much for the leading devs.

The procedure itself is not much shorter, but there's less room for errors, and syncing is simpler - actually nil, you always start from the current geany master.

— Reply to this email directly or view it on GitHub https://github.com/geany/geany/issues/764#issuecomment-159019989.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-159077567

As I read the protected branches they don't stop you pushing to the master branch, they just put a few requirements on that.

Indeed, the limitations are very clear... but I somehow read them as "can't have merges by outsiders". Wishful thinking.

Note that some of your steps below are once only, like forking on github

But you need to sync instead.

and some should be once only or at least rare like cloning locally.

Each time git gives me some unclear message, or I tried an advanced command and am unsure about my repository state. But yes, it's rare. :)

First off, branches aren't copies, they are just a "pointer" to a particular last commit, so there's virtually no overhead in having a hundred branches.

I didn't mean they are physical, and haven't complained about any machine overhead. They are hard for me, to keep in my head.

Just clone geany/geany [...] add your remote git remote add myname [...] and enjoy a simple life

Thank you. I will.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/764#issuecomment-159355900