Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Carsten Haitzler]

On Wed, 22 Nov 2017 20:13:48 + Mike Blumenkrantz
 said:

> I'm on fedora with meson 0.42.1 and ninja 1.8.2

Can you try doing the "build as user, install as root/sudo" and hit the issue
and details exactly what files are owned by root at that point and what file
the problem is with and why the permission problem is there? I just can't see
the source of the issue in my build trees.

> On Wed, Nov 22, 2017 at 1:08 PM Andrew Williams 
> wrote:
> 
> > Hi,
> >
> > I'm on Arch and generally try to stay up to date so maybe they have fixed
> > it?
> > Mike?
> >
> > On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher  wrote:
> >
> > > I can't reproduce that root owner ship issue right now.
> > > I made the changes to my scripts on the 2017/08/17
> > > at that time on my archlinux boxes ninja was 1.7.2 and meson was 0.41.2
> > > since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 then
> > > 0.43.0
> > > maybe it has been fixed in one of them fixed now.
> > > (but I won't dive into their respective repos to check that ;)
> > >
> > >
> > > On Wednesday 22 November 2017  20:51, Carsten Haitzler wrote :
> > > > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams <
> > a...@andywilliams.me>
> > > said:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm glad that it is not affecting you. Jeyzu and I both seem to have
> > > hit
> > > > > this issue (and I guess zmike too as described earlier).
> > > > > Some times after a "sudo ninja install" I can no longer "ninja" due
> > to
> > > > > permissions issues with files that have become root owned.
> > > > >
> > > > > It is unfortunate but it would be good to get a solution that works
> > > all the
> > > > > time for everyone if possible.
> > > >
> > > > I checked what files were root owned. I currently don't see a reason
> > why
> > > it
> > > > should fail. Someone show me a reason where it does fail (a file
> > written
> > > to as
> > > > root has to be overwritten as a user or it cannot be deleted as a
> > user).
> > > I
> > > > don't see it. perhaps its a bug in meson in an older version? or a
> > newer
> > > one?
> > > >
> > > > > Andy
> > > > >
> > > > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler 
> > > wrote:
> > > > >
> > > > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher  > >
> > > said:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I confirm, I had to add the above in my build script :
> > > > > > >
> > > > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log
> > > > > >
> > > > > >  7:14PM ~/C/e/build ⎇ master > ls -al
> > > > > > total 4.4M
> > > > > > 4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
> > > > > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
> > > > > > 1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
> > > > > >  64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log
> > > > > >
> > > > > > written not as root. (make ninja install was as root). ... ?
> > > > > >
> > > > > > > On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Compiling as root may be a bad thing but mike is right, ninja
> > > install
> > > > > > hits
> > > > > > > > log files and other - some times causing root ownership. I have
> > > seen it
> > > > > > > > occasionally myself and have had to either delete the build
> > tree
> > > or
> > > > > > chown
> > > > > > > > it to myself.
> > > > > > > >
> > > > > > > > Perhaps this is a bug we should be reporting but in the
> > meantime
> > > our
> > > > > > docs
> > > > > > > > should cover it somehow.
> > > > > > > >
> > > > > > > > Andy
> > > > > > > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler <
> > > ras...@rasterman.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > > > > > > > >  said:
> > > > > > > > >
> > > > > > > > > > The wording is intentional. The meson build has a tendency
> > > to touch
> > > > > > > > > > build files during the install phase (which must be run as
> > > root to
> > > > > > > > > > install to
> > > > > > > > > the
> > > > > > > > > > base system), meaning that failure to use sudo during
> > general
> > > > > > build will
> > > > > > > > > > fail for subsequent builds anyway due to permissions errors
> > > when
> > > > > > > > > attempting
> > > > > > > > > > to modify root-owned files.
> > > > > > > > >
> > > > > > > > > i have never had a permission error after a "sudo ninja
> > > install" to
> > > > > > just
> > > > > > > > > run
> > > > > > > > > ninja as me to rebuild whatever changed. it's just the gmo
> > > files (and
> > > > > > > > > install
> > > > > > > > > log which obviously is written as root) from gettext... and
> > > they are
> > > > > > only
> > > > > > > > > re-generated by root so ... root overwrites root files. you
> > can
> > > > > > delete

Re: [E-devel] Git Feature/ Proposal

[Simon Lees]

On 22/11/17 18:42, Andrew Williams wrote:
> Can we instead ask people to pull master into their branch before asking
> for review / merging it up to master? That’s pretty common practice - in
> fact for a long lived branch I would expect that to happen on a regular
> basis.
> 
> Andy

Yeah I presumed this would be a minimal expectation of any review, I
guess it should be explicitly documented somewhere.

> On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André  wrote:
> 
>> My problem is that those branches won't be in sync with master.
>> This will lead to merge conflicts. I am these days reviewing a lot of work
>> done in dev branches or phab patches and it almost never applies nicely on
>> master, because the interfaces change.
>> A lot of work is done in branches (model, c#, eo widgets, ...) and those
>> tasks are both long term and involve more than a single dev. They require
>> constant rebasing on master or the final rebase will be a nightmare. Right
>> now this is done by people pulling other devs branches, and then rebasing
>> onto master in their own dev branch.
>>
>> Rewriting history on a shared branch has major downsides too. No problem
>> for dev branches as there's only one committer, but anyone pulling a
>> rewritten history will endure pain.
>>
>> Honestly I don't have a solution.
>>
>> It's a move in the right direction, but I'm not sure it's solving the
>> problems I'm facing :(
>>
>>
>>
>> 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
>>
>>> Only problem would be the commit emails being resent (because
>>> technically they are new commits). One can mitigate that by first
>>> pushing them to a dev branch. Commits there have first been there
>>> don't trigger emails.
>>>
>>> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
>>>  wrote:
 In the issue where a significant rebase against master is necessary
>> then
 it's trivial enough to either push to a new feature branch or delete
>> and
 re-create the existing branch.

 On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:

> As Mike said, the rebase/sync to master is being done locally before
> the merge. If you are talking about keeping this branch in sync with
> master constantly while developing, yes it's a problem. But I guess
> it's not intended for long term features.
>
> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>  wrote:
>> I don't see a difference in the merge process? A feature branch
>>> should be
>> treated exactly the same as master; the only difference is that
>> it's a
>> branch which people must specifically pull in order to use instead
>> of
> being
>> master.
>>
>> When merging, you can either do a regular rebase/merge as in the git
>> practices documentation or you can choose to rebase/squash on the
> branched
>> commits prior to pushing the merge. There is no rewriting within the
>> branch, but you can still rewrite anything which has not been pushed
>>> to
>> master just prior to pushing it to master.
>>
>> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
>>> j...@videolan.org>
>> wrote:
>>
>>> Hey,
>>>
>>> If we can't rewrite history on those branches (rebase and push -f),
>>> how
>>> should we proceed with the merge to/from master?
>>> Usually when we merge a branch to master, we rebase it on top of
>>> master
>>> first and then rebase. That's how our history remains linear and
>>> simple.
>>>
>>> What's the idea here? I wonder.
>>>
>>> Thanks for implementing this btw,
>>>
>>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
>>>
 I'm not sure about jenkins, that's Stefan's role.

 Anyhow, pushed the changes according to the wiki. Please consider
 especially mentioning probies when you say "everyone can push
>> to".

 --
 Tom.

 On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
  wrote:
> I've added all the necessary info to the documentation at
>
>>>
> https://www.enlightenment.org/contrib/devs/git-guide.md#
>>> Feature_Branches
>
> If the jenkins concept is not possible then feel free to
>> remove,
>>> but
>>> the
> rest should be in line with what we want.
>
> On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
>>> wrote:
>
>> So what has been decided? What should I do? I need specs,
> preferably
>> already added to the git wiki page so there are docs for this
> thing.
>>
>> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>>> ras...@rasterman.com
>
>> wrote:
>>> On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>>>  

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Mike Blumenkrantz]

I'm on fedora with meson 0.42.1 and ninja 1.8.2

On Wed, Nov 22, 2017 at 1:08 PM Andrew Williams 
wrote:

> Hi,
>
> I'm on Arch and generally try to stay up to date so maybe they have fixed
> it?
> Mike?
>
> On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher  wrote:
>
> > I can't reproduce that root owner ship issue right now.
> > I made the changes to my scripts on the 2017/08/17
> > at that time on my archlinux boxes ninja was 1.7.2 and meson was 0.41.2
> > since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 then
> > 0.43.0
> > maybe it has been fixed in one of them fixed now.
> > (but I won't dive into their respective repos to check that ;)
> >
> >
> > On Wednesday 22 November 2017  20:51, Carsten Haitzler wrote :
> > > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams <
> a...@andywilliams.me>
> > said:
> > >
> > > > Hi,
> > > >
> > > > I'm glad that it is not affecting you. Jeyzu and I both seem to have
> > hit
> > > > this issue (and I guess zmike too as described earlier).
> > > > Some times after a "sudo ninja install" I can no longer "ninja" due
> to
> > > > permissions issues with files that have become root owned.
> > > >
> > > > It is unfortunate but it would be good to get a solution that works
> > all the
> > > > time for everyone if possible.
> > >
> > > I checked what files were root owned. I currently don't see a reason
> why
> > it
> > > should fail. Someone show me a reason where it does fail (a file
> written
> > to as
> > > root has to be overwritten as a user or it cannot be deleted as a
> user).
> > I
> > > don't see it. perhaps its a bug in meson in an older version? or a
> newer
> > one?
> > >
> > > > Andy
> > > >
> > > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler 
> > wrote:
> > > >
> > > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher  >
> > said:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I confirm, I had to add the above in my build script :
> > > > > >
> > > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log
> > > > >
> > > > >  7:14PM ~/C/e/build ⎇ master > ls -al
> > > > > total 4.4M
> > > > > 4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
> > > > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
> > > > > 1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
> > > > >  64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log
> > > > >
> > > > > written not as root. (make ninja install was as root). ... ?
> > > > >
> > > > > > On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > > > > > > Hi,
> > > > > > >
> > > > > > > Compiling as root may be a bad thing but mike is right, ninja
> > install
> > > > > hits
> > > > > > > log files and other - some times causing root ownership. I have
> > seen it
> > > > > > > occasionally myself and have had to either delete the build
> tree
> > or
> > > > > chown
> > > > > > > it to myself.
> > > > > > >
> > > > > > > Perhaps this is a bug we should be reporting but in the
> meantime
> > our
> > > > > docs
> > > > > > > should cover it somehow.
> > > > > > >
> > > > > > > Andy
> > > > > > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > > > > > > >  said:
> > > > > > > >
> > > > > > > > > The wording is intentional. The meson build has a tendency
> > to touch
> > > > > > > > > build files during the install phase (which must be run as
> > root to
> > > > > > > > > install to
> > > > > > > > the
> > > > > > > > > base system), meaning that failure to use sudo during
> general
> > > > > build will
> > > > > > > > > fail for subsequent builds anyway due to permissions errors
> > when
> > > > > > > > attempting
> > > > > > > > > to modify root-owned files.
> > > > > > > >
> > > > > > > > i have never had a permission error after a "sudo ninja
> > install" to
> > > > > just
> > > > > > > > run
> > > > > > > > ninja as me to rebuild whatever changed. it's just the gmo
> > files (and
> > > > > > > > install
> > > > > > > > log which obviously is written as root) from gettext... and
> > they are
> > > > > only
> > > > > > > > re-generated by root so ... root overwrites root files. you
> can
> > > > > delete
> > > > > > > > these
> > > > > > > > files because they are in a directory owned by you (the
> user).
> > > > > > > >
> > > > > > > > so where is the actual permission problem? a ninja && sudo
> > ninja
> > > > > install
> > > > > > > > will
> > > > > > > > succeed without permission problems (see above). you as a
> user
> > can
> > > > > delete
> > > > > > > > the
> > > > > > > > effected files too.
> > > > > > > >
> > > > > > > > but suggestion people compile as root is a bad idea.
> > > > > > > >
> > > > > > > > ???
> > > > > > > >
> > > > > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler <
> > > > > 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Andrew Williams]

Hi,

I'm on Arch and generally try to stay up to date so maybe they have fixed
it?
Mike?

On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher  wrote:

> I can't reproduce that root owner ship issue right now.
> I made the changes to my scripts on the 2017/08/17
> at that time on my archlinux boxes ninja was 1.7.2 and meson was 0.41.2
> since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 then
> 0.43.0
> maybe it has been fixed in one of them fixed now.
> (but I won't dive into their respective repos to check that ;)
>
>
> On Wednesday 22 November 2017  20:51, Carsten Haitzler wrote :
> > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams 
> said:
> >
> > > Hi,
> > >
> > > I'm glad that it is not affecting you. Jeyzu and I both seem to have
> hit
> > > this issue (and I guess zmike too as described earlier).
> > > Some times after a "sudo ninja install" I can no longer "ninja" due to
> > > permissions issues with files that have become root owned.
> > >
> > > It is unfortunate but it would be good to get a solution that works
> all the
> > > time for everyone if possible.
> >
> > I checked what files were root owned. I currently don't see a reason why
> it
> > should fail. Someone show me a reason where it does fail (a file written
> to as
> > root has to be overwritten as a user or it cannot be deleted as a user).
> I
> > don't see it. perhaps its a bug in meson in an older version? or a newer
> one?
> >
> > > Andy
> > >
> > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler 
> wrote:
> > >
> > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher 
> said:
> > > >
> > > > > Hi,
> > > > >
> > > > > I confirm, I had to add the above in my build script :
> > > > >
> > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log
> > > >
> > > >  7:14PM ~/C/e/build ⎇ master > ls -al
> > > > total 4.4M
> > > > 4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
> > > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
> > > > 1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
> > > >  64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log
> > > >
> > > > written not as root. (make ninja install was as root). ... ?
> > > >
> > > > > On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > > > > > Hi,
> > > > > >
> > > > > > Compiling as root may be a bad thing but mike is right, ninja
> install
> > > > hits
> > > > > > log files and other - some times causing root ownership. I have
> seen it
> > > > > > occasionally myself and have had to either delete the build tree
> or
> > > > chown
> > > > > > it to myself.
> > > > > >
> > > > > > Perhaps this is a bug we should be reporting but in the meantime
> our
> > > > docs
> > > > > > should cover it somehow.
> > > > > >
> > > > > > Andy
> > > > > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler <
> ras...@rasterman.com>
> > > > wrote:
> > > > > >
> > > > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > > > > > >  said:
> > > > > > >
> > > > > > > > The wording is intentional. The meson build has a tendency
> to touch
> > > > > > > > build files during the install phase (which must be run as
> root to
> > > > > > > > install to
> > > > > > > the
> > > > > > > > base system), meaning that failure to use sudo during general
> > > > build will
> > > > > > > > fail for subsequent builds anyway due to permissions errors
> when
> > > > > > > attempting
> > > > > > > > to modify root-owned files.
> > > > > > >
> > > > > > > i have never had a permission error after a "sudo ninja
> install" to
> > > > just
> > > > > > > run
> > > > > > > ninja as me to rebuild whatever changed. it's just the gmo
> files (and
> > > > > > > install
> > > > > > > log which obviously is written as root) from gettext... and
> they are
> > > > only
> > > > > > > re-generated by root so ... root overwrites root files. you can
> > > > delete
> > > > > > > these
> > > > > > > files because they are in a directory owned by you (the user).
> > > > > > >
> > > > > > > so where is the actual permission problem? a ninja && sudo
> ninja
> > > > install
> > > > > > > will
> > > > > > > succeed without permission problems (see above). you as a user
> can
> > > > delete
> > > > > > > the
> > > > > > > effected files too.
> > > > > > >
> > > > > > > but suggestion people compile as root is a bad idea.
> > > > > > >
> > > > > > > ???
> > > > > > >
> > > > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler <
> > > > ras...@rasterman.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > > > > > > >  said:
> > > > > > > > >
> > > > > > > > > > Issues had been found at an inconvenient time during
> review,
> > > > so I
> > > > > > > left
> > > > > > > > > the
> > > > > > > > > > branch unmerged so that someone could either push while
> I was
> > > 

Re: [E-devel] FOSDEM

[Al Poole]

I can pay

On Wed, Nov 22, 2017 at 6:02 PM, Andrew Williams 
wrote:

> Hi,
>
> The supplier I work with does not do embroidery.
> Does anyone who will be attending Fosdem have the ability to get a full
> shirt with stitching organised?
>
> If not should I go ahead with a t-shirt or do folk feel strongly that it is
> not suitable for us?
>
> Thanks,
> Andy
>
> p.s. still wondering if folk would pay for their own shirt or if I need to
> get sponsorship for this?
>
> On Thu, 9 Nov 2017 at 00:24 Carsten Haitzler  wrote:
>
> > On Wed, 08 Nov 2017 22:05:07 + Andrew Williams  >
> > said:
> >
> > > Hi,
> > >
> > > I reckon stickers are a minimum :) not sure if we can afford more than
> > that
> > > to give away.
> > >
> > > I also wondered if we should get some new t-shirts - not to give away
> but
> > > for a little branding and visibility. Would folk be willing to pay for
> > > their own shirt?
> > >
> > > I was wondering about “Enlightenment” (with logo) on the front and
> maybe
> > > “built on EFL” on the back :)
> >
> > Can we do more stylish than a t-shirt? Like... A proper collared shirt
> > maybe
> > with the logo embroidered? grey/black with white embroidery? :)
> >
> > > Looking forward to it,
> > > Andy
> > > On Mon, 23 Oct 2017 at 14:31, Philippe Caseiro 
> > wrote:
> > >
> > > > Hi !!
> > > >
> > > >Stand request posted !
> > > >
> > > >Now, I will work on some goodies !
> > > >
> > > >Some ideas or proposals ?
> > > >
> > > > Regards
> > > >
> > > > Le mercredi 11 octobre 2017 14:51:03 CEST, Philippe Caseiro a écrit :
> > > > > Le mercredi 11 octobre 2017 13:19:42 CEST, Andrew Williams a écrit
> :
> > > > >> Hi,
> > > > >>
> > > > >> Good shout! I think I could make it this year and would be happy
> to
> > help
> > > > >> with the stand and/or put forward a talk (probably around edi
> > > > >> ;) or getting
> > > > >> into efl).
> > > > >
> > > > > Great !
> > > > >
> > > > >>
> > > > >> One proviso: we would have to do it properly - some fixed
> > > > >> demos, a story to
> > > > >> tell and probably some stickers too...
> > > > >>
> > > > >> An empty table with a name behind us made me sad :(
> > > > >
> > > > > Yes me to this year we will try to have a nice stand !
> > > > >
> > > > >
> > > >
> > > > --
> > > > Philippe Caseiro
> > > >
> > > > Responsable Cadoles Services & Solutions
> > > > Ingénieur logiciels libres
> > > >
> > > > https://www.cadoles.com
> > > >
> > > >
> > > >
> > > >
> > 
> --
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> > >
> > 
> --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > Carsten Haitzler - ras...@rasterman.com
> >
> > --
> http://andywilliams.me
> http://ajwillia.ms
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FOSDEM

[Andrew Williams]

Hi,

The supplier I work with does not do embroidery.
Does anyone who will be attending Fosdem have the ability to get a full
shirt with stitching organised?

If not should I go ahead with a t-shirt or do folk feel strongly that it is
not suitable for us?

Thanks,
Andy

p.s. still wondering if folk would pay for their own shirt or if I need to
get sponsorship for this?

On Thu, 9 Nov 2017 at 00:24 Carsten Haitzler  wrote:

> On Wed, 08 Nov 2017 22:05:07 + Andrew Williams 
> said:
>
> > Hi,
> >
> > I reckon stickers are a minimum :) not sure if we can afford more than
> that
> > to give away.
> >
> > I also wondered if we should get some new t-shirts - not to give away but
> > for a little branding and visibility. Would folk be willing to pay for
> > their own shirt?
> >
> > I was wondering about “Enlightenment” (with logo) on the front and maybe
> > “built on EFL” on the back :)
>
> Can we do more stylish than a t-shirt? Like... A proper collared shirt
> maybe
> with the logo embroidered? grey/black with white embroidery? :)
>
> > Looking forward to it,
> > Andy
> > On Mon, 23 Oct 2017 at 14:31, Philippe Caseiro 
> wrote:
> >
> > > Hi !!
> > >
> > >Stand request posted !
> > >
> > >Now, I will work on some goodies !
> > >
> > >Some ideas or proposals ?
> > >
> > > Regards
> > >
> > > Le mercredi 11 octobre 2017 14:51:03 CEST, Philippe Caseiro a écrit :
> > > > Le mercredi 11 octobre 2017 13:19:42 CEST, Andrew Williams a écrit :
> > > >> Hi,
> > > >>
> > > >> Good shout! I think I could make it this year and would be happy to
> help
> > > >> with the stand and/or put forward a talk (probably around edi
> > > >> ;) or getting
> > > >> into efl).
> > > >
> > > > Great !
> > > >
> > > >>
> > > >> One proviso: we would have to do it properly - some fixed
> > > >> demos, a story to
> > > >> tell and probably some stickers too...
> > > >>
> > > >> An empty table with a name behind us made me sad :(
> > > >
> > > > Yes me to this year we will try to have a nice stand !
> > > >
> > > >
> > >
> > > --
> > > Philippe Caseiro
> > >
> > > Responsable Cadoles Services & Solutions
> > > Ingénieur logiciels libres
> > >
> > > https://www.cadoles.com
> > >
> > >
> > >
> > >
> --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
> --
http://andywilliams.me
http://ajwillia.ms
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Enlightenment Developer Days 2018 location proposals

[Stefan Schmidt]

Hello.


The end of the year is near and we should start thinking about the next edition 
of the Enlightenment developer days.


So far we have been doing good with starting to source a suitable location 
first and find the best dates after that. I would go the same
route this year.

Loking back at last years location voting we can see that Malta was on the top 
position together with Toulouse. With a close follow up of
Paris and Edinburgh.

https://phab.enlightenment.org/V27


The questions comes up if our location proposals are still up to date. Are the 
persons willing to do the local organization still available?
(move, different employer). If your name is listed on the location proposals 
list please clarify if this is still valid or not. Simply
remove it if not.

https://phab.enlightenment.org/w/events/location_proposals/


One location that is not listed on the wiki which I brought up at last years 
event was Bangkok. As far as I know we have nobody in our
community from there but if we would like to aim for a non EU event again this 
might be a sweet spot. In terms of flight prices from Europe
and being in good reach for all Asia. Just an idea, we would need to find local 
help if people are interested in it.


Please update the location proposals and start your discussion here.


regards

Stefan Schmidt


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Git Feature/ Proposal

[Mike Blumenkrantz]

I think the most reliable method for handling rebases onto master is if
people working on the branch just communicate that there will be a rebase
at X time and then someone does the delete -> rebase -> create cycle.
Anyone interested in doing review can just request a rebase if there's been
significant deviation.

This is not an automated solution, but communication can easily make this a
non-issue.

On Wed, Nov 22, 2017 at 5:16 AM Carsten Haitzler 
wrote:

> On Wed, 22 Nov 2017 08:12:13 + Andrew Williams 
> said:
>
> > Can we instead ask people to pull master into their branch before asking
> > for review / merging it up to master? That’s pretty common practice - in
> > fact for a long lived branch I would expect that to happen on a regular
> > basis.
>
> That would be at a minimum.
>
> > Andy
> > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André 
> wrote:
> >
> > > My problem is that those branches won't be in sync with master.
> > > This will lead to merge conflicts. I am these days reviewing a lot of
> work
> > > done in dev branches or phab patches and it almost never applies
> nicely on
> > > master, because the interfaces change.
> > > A lot of work is done in branches (model, c#, eo widgets, ...) and
> those
> > > tasks are both long term and involve more than a single dev. They
> require
> > > constant rebasing on master or the final rebase will be a nightmare.
> Right
> > > now this is done by people pulling other devs branches, and then
> rebasing
> > > onto master in their own dev branch.
> > >
> > > Rewriting history on a shared branch has major downsides too. No
> problem
> > > for dev branches as there's only one committer, but anyone pulling a
> > > rewritten history will endure pain.
> > >
> > > Honestly I don't have a solution.
> > >
> > > It's a move in the right direction, but I'm not sure it's solving the
> > > problems I'm facing :(
> > >
> > >
> > >
> > > 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
> > >
> > > > Only problem would be the commit emails being resent (because
> > > > technically they are new commits). One can mitigate that by first
> > > > pushing them to a dev branch. Commits there have first been there
> > > > don't trigger emails.
> > > >
> > > > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> > > >  wrote:
> > > > > In the issue where a significant rebase against master is necessary
> > > then
> > > > > it's trivial enough to either push to a new feature branch or
> delete
> > > and
> > > > > re-create the existing branch.
> > > > >
> > > > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> > > > >
> > > > >> As Mike said, the rebase/sync to master is being done locally
> before
> > > > >> the merge. If you are talking about keeping this branch in sync
> with
> > > > >> master constantly while developing, yes it's a problem. But I
> guess
> > > > >> it's not intended for long term features.
> > > > >>
> > > > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> > > > >>  wrote:
> > > > >> > I don't see a difference in the merge process? A feature branch
> > > > should be
> > > > >> > treated exactly the same as master; the only difference is that
> > > it's a
> > > > >> > branch which people must specifically pull in order to use
> instead
> > > of
> > > > >> being
> > > > >> > master.
> > > > >> >
> > > > >> > When merging, you can either do a regular rebase/merge as in
> the git
> > > > >> > practices documentation or you can choose to rebase/squash on
> the
> > > > >> branched
> > > > >> > commits prior to pushing the merge. There is no rewriting
> within the
> > > > >> > branch, but you can still rewrite anything which has not been
> pushed
> > > > to
> > > > >> > master just prior to pushing it to master.
> > > > >> >
> > > > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> > > > j...@videolan.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> Hey,
> > > > >> >>
> > > > >> >> If we can't rewrite history on those branches (rebase and push
> -f),
> > > > how
> > > > >> >> should we proceed with the merge to/from master?
> > > > >> >> Usually when we merge a branch to master, we rebase it on top
> of
> > > > master
> > > > >> >> first and then rebase. That's how our history remains linear
> and
> > > > simple.
> > > > >> >>
> > > > >> >> What's the idea here? I wonder.
> > > > >> >>
> > > > >> >> Thanks for implementing this btw,
> > > > >> >>
> > > > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> > > > >> >>
> > > > >> >> > I'm not sure about jenkins, that's Stefan's role.
> > > > >> >> >
> > > > >> >> > Anyhow, pushed the changes according to the wiki. Please
> consider
> > > > >> >> > especially mentioning probies when you say "everyone can push
> > > to".
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Tom.
> > > > >> >> >
> > > > >> >> > On Mon, Nov 20, 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Jérémy Zurcher]

I can't reproduce that root owner ship issue right now.
I made the changes to my scripts on the 2017/08/17
at that time on my archlinux boxes ninja was 1.7.2 and meson was 0.41.2
since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 then 0.43.0
maybe it has been fixed in one of them fixed now.
(but I won't dive into their respective repos to check that ;)


On Wednesday 22 November 2017  20:51, Carsten Haitzler wrote :
> On Wed, 22 Nov 2017 10:36:36 + Andrew Williams  
> said:
> 
> > Hi,
> > 
> > I'm glad that it is not affecting you. Jeyzu and I both seem to have hit
> > this issue (and I guess zmike too as described earlier).
> > Some times after a "sudo ninja install" I can no longer "ninja" due to
> > permissions issues with files that have become root owned.
> > 
> > It is unfortunate but it would be good to get a solution that works all the
> > time for everyone if possible.
> 
> I checked what files were root owned. I currently don't see a reason why it
> should fail. Someone show me a reason where it does fail (a file written to as
> root has to be overwritten as a user or it cannot be deleted as a user). I
> don't see it. perhaps its a bug in meson in an older version? or a newer one?
> 
> > Andy
> > 
> > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler  wrote:
> > 
> > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher  said:
> > >
> > > > Hi,
> > > >
> > > > I confirm, I had to add the above in my build script :
> > > >
> > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log
> > >
> > >  7:14PM ~/C/e/build ⎇ master > ls -al
> > > total 4.4M
> > > 4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
> > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
> > > 1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
> > >  64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log
> > >
> > > written not as root. (make ninja install was as root). ... ?
> > >
> > > > On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > > > > Hi,
> > > > >
> > > > > Compiling as root may be a bad thing but mike is right, ninja install
> > > hits
> > > > > log files and other - some times causing root ownership. I have seen 
> > > > > it
> > > > > occasionally myself and have had to either delete the build tree or
> > > chown
> > > > > it to myself.
> > > > >
> > > > > Perhaps this is a bug we should be reporting but in the meantime our
> > > docs
> > > > > should cover it somehow.
> > > > >
> > > > > Andy
> > > > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler 
> > > wrote:
> > > > >
> > > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > > > > >  said:
> > > > > >
> > > > > > > The wording is intentional. The meson build has a tendency to 
> > > > > > > touch
> > > > > > > build files during the install phase (which must be run as root to
> > > > > > > install to
> > > > > > the
> > > > > > > base system), meaning that failure to use sudo during general
> > > build will
> > > > > > > fail for subsequent builds anyway due to permissions errors when
> > > > > > attempting
> > > > > > > to modify root-owned files.
> > > > > >
> > > > > > i have never had a permission error after a "sudo ninja install" to
> > > just
> > > > > > run
> > > > > > ninja as me to rebuild whatever changed. it's just the gmo files 
> > > > > > (and
> > > > > > install
> > > > > > log which obviously is written as root) from gettext... and they are
> > > only
> > > > > > re-generated by root so ... root overwrites root files. you can
> > > delete
> > > > > > these
> > > > > > files because they are in a directory owned by you (the user).
> > > > > >
> > > > > > so where is the actual permission problem? a ninja && sudo ninja
> > > install
> > > > > > will
> > > > > > succeed without permission problems (see above). you as a user can
> > > delete
> > > > > > the
> > > > > > effected files too.
> > > > > >
> > > > > > but suggestion people compile as root is a bad idea.
> > > > > >
> > > > > > ???
> > > > > >
> > > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler <
> > > ras...@rasterman.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > > > > > >  said:
> > > > > > > >
> > > > > > > > > Issues had been found at an inconvenient time during review,
> > > so I
> > > > > > left
> > > > > > > > the
> > > > > > > > > branch unmerged so that someone could either push while I was
> > > gone
> > > > > > or I
> > > > > > > > > could push when I returned.
> > > > > > > >
> > > > > > > > I saw you pushed now. so we know the status. This also clears up
> > > the
> > > > > > build
> > > > > > > > system state. I guess I should ensure it's documented. I see
> > > README
> > > > > > > > changed but
> > > > > > > > i am not sure it's correct as it's going to do a build as
> 

[E-devel] Pre-release tarballs for efl 1.20.6

[Stefan Schmidt]

Hello.

I just uploaded the pre-release tarballs for 1.20.6.

If I hear nothing problematic within the next 24 hours, I will do the
final release on tomorrow.

https://download.enlightenment.org/pre-releases/efl-1.20.6-pre.tar.gz
66ee285d1a8cc721abf2e6aa632daa7bf645e5c4647561318b565ee81a8564c3

https://download.enlightenment.org/pre-releases/efl-1.20.6-pre.tar.xz
56c67ea77435753a4f324a0a13488ba58f4ed7eb35a97c1a354fdc79c39a32c1

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Website Table of Contents

[Andrew Williams]

Hi,

Unfortunately I am not following what you mean by these artefacts, can you
please provide screenshots? With regards to the transparent overlay I did
see that in a browser, I reset the cache and it went away.

There is a graphical glitch whereby it /looks/ like the code div goes under
the ToC but it actually doesn't, that is just the background colour - no
content.

I will see if we can provide a way to dismiss it if you don't like the
feature.

Andy

On Wed, 22 Nov 2017 at 11:58 Carsten Haitzler  wrote:

> On Wed, 22 Nov 2017 10:29:29 + Andrew Williams 
> said:
>
> > Hi,
> >
> > If you are seeing broken rendering please refresh the cache - there are
> CSS
> > changes in there that will need to be grabbed as well as the content.
>
> shift-reloaded. same story. overlaps. :)
>
> > In your screenshot I don't know what you mean by "gutter" - the screen is
> > not wide enough for it to have moved into the gutter, which it will do
> when
> > possible to make the most of the fixed-width content.
>
> between the top menu bar and content of screen thus pushing all the content
> down by the size of the nav ToC.
>
> > The sidebar is split into 2 - at the top is a navigation for that
> namespace
> > (can change per-namespace) and the Page Contents is generated based on
> the
> > headings within a page. As you say the content here can change and this
> is
> > just to get things rolling. The main objection to ToC was that it could
> not
> > look good, so I am trying to make that work after which the content could
> > be finalised. The tutorials indeed could be collapsed - but we wanted to
> > have enough content in here to make it meaningful to discuss.
>
> Well It probably would be good to collapse this as it is overlapping
> content ... or specifically allow it to collapse to get it out of the way
> when
> someone needs that content.
>
> > I don't know what you mean about "content underneath" - this does not
> cover
> > any content, it displaces it. And on a wider window it does not even
> > displace any content. We are trying to avoid dropdowns as much as
> possible,
> > as discussed in another thread they are not very discoverable etc.
>
> It overlaps the the divs with the function prototypes in them. the divs are
> going under the ToC. you can see at the bottom of the.
>
> > One main aim of this is to get some consistency and flow over the site.
> > Many, many of our pages have built in ToC or Navigation to work around
> the
> > fact that we have none so making a standard space where this is presented
> > should help a lot for those struggling to find the right documentation.
>
> I never really thought that was a good idea. Someone decided to add it in
> by
> hand. it should not have been added by hand at all. It is duplicating what
> can
> be automated. Then the only question is if it should be there at all. But
> Having it collapse would be good to get it out of the way when not needed
> or
> wanted. ALLOW it to collapse. Expand it by default. All that is is then a
> "collapse/expand" arrow/button at the bottom of the ToC to do this.
>
> > Thanks,
> > Andy
> >
> > On Wed, 22 Nov 2017 at 00:29 Carsten Haitzler 
> wrote:
> >
> > > On Mon, 20 Nov 2017 12:18:09 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > So I've tried to get a ToC appended to the nav sidebar and I'm not
> > > > disappointed with the result.
> > > >
> > >
> https://www.enlightenment.org/ss/display.php?image=e-5a12a60dc3d772.36151853.jpg
> > > >
> > > > If there is space the bar is static on the top right of the screen,
> if
> > > > there is not a wide enough gutter then it inlines at the top right
> of the
> > > > content.
> > >
> > > It seems this is broken (overlaps a lot of content - just by luck the
> > > content
> > > doesn't have long enough lines there to be hidden):
> > >
> > >   https://www.enlightenment.org/develop/api/class/efl/object
> > >
> > >   http://www.enlightenment.org/ss/e-5a14c363eec9d0.43575629.png
> > >
> > > It shouldn't "gutter" IMHO in this case either like on mobile like
> > > displays. I
> > > think you need a better solution. Most of that ToC IMHO is not useful
> while
> > > reading reference docs. Especially the Tutorials, Setup and APIs.
> Tutorials
> > > there is hopefully going to expand to 100's of items  making this
> pretty
> > > pointless. The Page Contents is the useful part as a "jump to this
> > > section". I
> > > assume for now most of that is "sample content" and will be
> reconsidered in
> > > future?
> > >
> > > I am thinking this should really just be a dropdown menu like Options
> etc.
> > > perhaps displayed by default? At least so I can hide it and read the
> > > content
> > > underneath?
> > >
> > > > It appears when there are 3 or more headings at level 2 and 3 - that
> > > means
> > > > we ignore top level headings (usually a page title) and expand 1
> level if
> > > > the 

Re: [E-devel] Website Table of Contents

[Carsten Haitzler]

On Wed, 22 Nov 2017 10:29:29 + Andrew Williams  said:

> Hi,
> 
> If you are seeing broken rendering please refresh the cache - there are CSS
> changes in there that will need to be grabbed as well as the content.

shift-reloaded. same story. overlaps. :)

> In your screenshot I don't know what you mean by "gutter" - the screen is
> not wide enough for it to have moved into the gutter, which it will do when
> possible to make the most of the fixed-width content.

between the top menu bar and content of screen thus pushing all the content
down by the size of the nav ToC.

> The sidebar is split into 2 - at the top is a navigation for that namespace
> (can change per-namespace) and the Page Contents is generated based on the
> headings within a page. As you say the content here can change and this is
> just to get things rolling. The main objection to ToC was that it could not
> look good, so I am trying to make that work after which the content could
> be finalised. The tutorials indeed could be collapsed - but we wanted to
> have enough content in here to make it meaningful to discuss.

Well It probably would be good to collapse this as it is overlapping
content ... or specifically allow it to collapse to get it out of the way when
someone needs that content.

> I don't know what you mean about "content underneath" - this does not cover
> any content, it displaces it. And on a wider window it does not even
> displace any content. We are trying to avoid dropdowns as much as possible,
> as discussed in another thread they are not very discoverable etc.

It overlaps the the divs with the function prototypes in them. the divs are
going under the ToC. you can see at the bottom of the.

> One main aim of this is to get some consistency and flow over the site.
> Many, many of our pages have built in ToC or Navigation to work around the
> fact that we have none so making a standard space where this is presented
> should help a lot for those struggling to find the right documentation.

I never really thought that was a good idea. Someone decided to add it in by
hand. it should not have been added by hand at all. It is duplicating what can
be automated. Then the only question is if it should be there at all. But
Having it collapse would be good to get it out of the way when not needed or
wanted. ALLOW it to collapse. Expand it by default. All that is is then a
"collapse/expand" arrow/button at the bottom of the ToC to do this.

> Thanks,
> Andy
> 
> On Wed, 22 Nov 2017 at 00:29 Carsten Haitzler  wrote:
> 
> > On Mon, 20 Nov 2017 12:18:09 + Andrew Williams 
> > said:
> >
> > > Hi,
> > >
> > > So I've tried to get a ToC appended to the nav sidebar and I'm not
> > > disappointed with the result.
> > >
> > https://www.enlightenment.org/ss/display.php?image=e-5a12a60dc3d772.36151853.jpg
> > >
> > > If there is space the bar is static on the top right of the screen, if
> > > there is not a wide enough gutter then it inlines at the top right of the
> > > content.
> >
> > It seems this is broken (overlaps a lot of content - just by luck the
> > content
> > doesn't have long enough lines there to be hidden):
> >
> >   https://www.enlightenment.org/develop/api/class/efl/object
> >
> >   http://www.enlightenment.org/ss/e-5a14c363eec9d0.43575629.png
> >
> > It shouldn't "gutter" IMHO in this case either like on mobile like
> > displays. I
> > think you need a better solution. Most of that ToC IMHO is not useful while
> > reading reference docs. Especially the Tutorials, Setup and APIs. Tutorials
> > there is hopefully going to expand to 100's of items  making this pretty
> > pointless. The Page Contents is the useful part as a "jump to this
> > section". I
> > assume for now most of that is "sample content" and will be reconsidered in
> > future?
> >
> > I am thinking this should really just be a dropdown menu like Options etc.
> > perhaps displayed by default? At least so I can hide it and read the
> > content
> > underneath?
> >
> > > It appears when there are 3 or more headings at level 2 and 3 - that
> > means
> > > we ignore top level headings (usually a page title) and expand 1 level if
> > > the current top level area has child elements. Most of this is the ToC
> > > plugin in dokuwiki and works quite well.
> > >
> > > Comments welcome, plenty of opportunity to adapt it to suit our style.
> > > Andy
> > >
> > > On Wed, 8 Nov 2017 at 07:27 Carsten Haitzler 
> > wrote:
> > >
> > > > On Tue, 07 Nov 2017 15:59:24 + Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > Hi,
> > > > >
> > > > > The amount of space it takes up is a stylistic issue - our template
> > > > > explicitly reserves 1/4 of the screen for a ToC which is clearly not
> > a
> > > > > requirement.
> > > >
> > > > that was my major thing about it. stylistic. :) also the original css
> > for
> > > > it
> > > > was a bit blergh and i didn't 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Carsten Haitzler]

On Wed, 22 Nov 2017 10:36:36 + Andrew Williams  said:

> Hi,
> 
> I'm glad that it is not affecting you. Jeyzu and I both seem to have hit
> this issue (and I guess zmike too as described earlier).
> Some times after a "sudo ninja install" I can no longer "ninja" due to
> permissions issues with files that have become root owned.
> 
> It is unfortunate but it would be good to get a solution that works all the
> time for everyone if possible.

I checked what files were root owned. I currently don't see a reason why it
should fail. Someone show me a reason where it does fail (a file written to as
root has to be overwritten as a user or it cannot be deleted as a user). I
don't see it. perhaps its a bug in meson in an older version? or a newer one?

> Andy
> 
> On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler  wrote:
> 
> > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher  said:
> >
> > > Hi,
> > >
> > > I confirm, I had to add the above in my build script :
> > >
> > > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log
> >
> >  7:14PM ~/C/e/build ⎇ master > ls -al
> > total 4.4M
> > 4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
> > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
> > 1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
> >  64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log
> >
> > written not as root. (make ninja install was as root). ... ?
> >
> > > On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > > > Hi,
> > > >
> > > > Compiling as root may be a bad thing but mike is right, ninja install
> > hits
> > > > log files and other - some times causing root ownership. I have seen it
> > > > occasionally myself and have had to either delete the build tree or
> > chown
> > > > it to myself.
> > > >
> > > > Perhaps this is a bug we should be reporting but in the meantime our
> > docs
> > > > should cover it somehow.
> > > >
> > > > Andy
> > > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler 
> > wrote:
> > > >
> > > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > > > >  said:
> > > > >
> > > > > > The wording is intentional. The meson build has a tendency to touch
> > > > > > build files during the install phase (which must be run as root to
> > > > > > install to
> > > > > the
> > > > > > base system), meaning that failure to use sudo during general
> > build will
> > > > > > fail for subsequent builds anyway due to permissions errors when
> > > > > attempting
> > > > > > to modify root-owned files.
> > > > >
> > > > > i have never had a permission error after a "sudo ninja install" to
> > just
> > > > > run
> > > > > ninja as me to rebuild whatever changed. it's just the gmo files (and
> > > > > install
> > > > > log which obviously is written as root) from gettext... and they are
> > only
> > > > > re-generated by root so ... root overwrites root files. you can
> > delete
> > > > > these
> > > > > files because they are in a directory owned by you (the user).
> > > > >
> > > > > so where is the actual permission problem? a ninja && sudo ninja
> > install
> > > > > will
> > > > > succeed without permission problems (see above). you as a user can
> > delete
> > > > > the
> > > > > effected files too.
> > > > >
> > > > > but suggestion people compile as root is a bad idea.
> > > > >
> > > > > ???
> > > > >
> > > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > > > > >  said:
> > > > > > >
> > > > > > > > Issues had been found at an inconvenient time during review,
> > so I
> > > > > left
> > > > > > > the
> > > > > > > > branch unmerged so that someone could either push while I was
> > gone
> > > > > or I
> > > > > > > > could push when I returned.
> > > > > > >
> > > > > > > I saw you pushed now. so we know the status. This also clears up
> > the
> > > > > build
> > > > > > > system state. I guess I should ensure it's documented. I see
> > README
> > > > > > > changed but
> > > > > > > i am not sure it's correct as it's going to do a build as
> > root... i'll
> > > > > deal
> > > > > > > with it. :)
> > > > > > >
> > > > > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler <
> > > > > ras...@rasterman.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > > > > > > a...@andywilliams.me>
> > > > > > > > > said:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > As the autotool/Makefiles are still in place I fixed the
> > build
> > > > > for
> > > > > > > users
> > > > > > > > > > not yet using the E meson build.
> > > > > > > > >
> > > > > > > > > i was assuming autotools was dead - mike did say he'd push
> > his
> > > > > > > autotools
> > > 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Andrew Williams]

Hi,

I'm glad that it is not affecting you. Jeyzu and I both seem to have hit
this issue (and I guess zmike too as described earlier).
Some times after a "sudo ninja install" I can no longer "ninja" due to
permissions issues with files that have become root owned.

It is unfortunate but it would be good to get a solution that works all the
time for everyone if possible.

Andy

On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler  wrote:

> On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher  said:
>
> > Hi,
> >
> > I confirm, I had to add the above in my build script :
> >
> > sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log
>
>  7:14PM ~/C/e/build ⎇ master > ls -al
> total 4.4M
> 4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
> 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
> 1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
>  64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log
>
> written not as root. (make ninja install was as root). ... ?
>
> > On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > > Hi,
> > >
> > > Compiling as root may be a bad thing but mike is right, ninja install
> hits
> > > log files and other - some times causing root ownership. I have seen it
> > > occasionally myself and have had to either delete the build tree or
> chown
> > > it to myself.
> > >
> > > Perhaps this is a bug we should be reporting but in the meantime our
> docs
> > > should cover it somehow.
> > >
> > > Andy
> > > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler 
> wrote:
> > >
> > > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > > >  said:
> > > >
> > > > > The wording is intentional. The meson build has a tendency to touch
> > > > > build files during the install phase (which must be run as root to
> > > > > install to
> > > > the
> > > > > base system), meaning that failure to use sudo during general
> build will
> > > > > fail for subsequent builds anyway due to permissions errors when
> > > > attempting
> > > > > to modify root-owned files.
> > > >
> > > > i have never had a permission error after a "sudo ninja install" to
> just
> > > > run
> > > > ninja as me to rebuild whatever changed. it's just the gmo files (and
> > > > install
> > > > log which obviously is written as root) from gettext... and they are
> only
> > > > re-generated by root so ... root overwrites root files. you can
> delete
> > > > these
> > > > files because they are in a directory owned by you (the user).
> > > >
> > > > so where is the actual permission problem? a ninja && sudo ninja
> install
> > > > will
> > > > succeed without permission problems (see above). you as a user can
> delete
> > > > the
> > > > effected files too.
> > > >
> > > > but suggestion people compile as root is a bad idea.
> > > >
> > > > ???
> > > >
> > > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler <
> ras...@rasterman.com>
> > > > > wrote:
> > > > >
> > > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > > > >  said:
> > > > > >
> > > > > > > Issues had been found at an inconvenient time during review,
> so I
> > > > left
> > > > > > the
> > > > > > > branch unmerged so that someone could either push while I was
> gone
> > > > or I
> > > > > > > could push when I returned.
> > > > > >
> > > > > > I saw you pushed now. so we know the status. This also clears up
> the
> > > > build
> > > > > > system state. I guess I should ensure it's documented. I see
> README
> > > > > > changed but
> > > > > > i am not sure it's correct as it's going to do a build as
> root... i'll
> > > > deal
> > > > > > with it. :)
> > > > > >
> > > > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler <
> > > > ras...@rasterman.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > > > > > a...@andywilliams.me>
> > > > > > > > said:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > As the autotool/Makefiles are still in place I fixed the
> build
> > > > for
> > > > > > users
> > > > > > > > > not yet using the E meson build.
> > > > > > > >
> > > > > > > > i was assuming autotools was dead - mike did say he'd push
> his
> > > > > > autotools
> > > > > > > > removal branch "in a day or 2 if no issues"... that about 1-2
> > > > > > > > weeks
> > > > > > back. i
> > > > > > > > didn't see it happen and didn't hear of issues...
> > > > > > > >
> > > > > > > > are there any? I'd consider merging his branch to remove
> autofoo
> > > > > > > > at
> > > > > > this
> > > > > > > > point.
> > > > > > > > If meson has issues it should be tested and they should be
> fixed.
> > > > > > > >
> > > > > > > > > Andy
> > > > > > > > >
> > > > > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler <
> > > > ras...@rasterman.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > raster pushed a 

Re: [E-devel] Website Table of Contents

[Andrew Williams]

Hi,

If you are seeing broken rendering please refresh the cache - there are CSS
changes in there that will need to be grabbed as well as the content.

In your screenshot I don't know what you mean by "gutter" - the screen is
not wide enough for it to have moved into the gutter, which it will do when
possible to make the most of the fixed-width content.

The sidebar is split into 2 - at the top is a navigation for that namespace
(can change per-namespace) and the Page Contents is generated based on the
headings within a page. As you say the content here can change and this is
just to get things rolling. The main objection to ToC was that it could not
look good, so I am trying to make that work after which the content could
be finalised. The tutorials indeed could be collapsed - but we wanted to
have enough content in here to make it meaningful to discuss.

I don't know what you mean about "content underneath" - this does not cover
any content, it displaces it. And on a wider window it does not even
displace any content. We are trying to avoid dropdowns as much as possible,
as discussed in another thread they are not very discoverable etc.

One main aim of this is to get some consistency and flow over the site.
Many, many of our pages have built in ToC or Navigation to work around the
fact that we have none so making a standard space where this is presented
should help a lot for those struggling to find the right documentation.

Thanks,
Andy

On Wed, 22 Nov 2017 at 00:29 Carsten Haitzler  wrote:

> On Mon, 20 Nov 2017 12:18:09 + Andrew Williams 
> said:
>
> > Hi,
> >
> > So I've tried to get a ToC appended to the nav sidebar and I'm not
> > disappointed with the result.
> >
> https://www.enlightenment.org/ss/display.php?image=e-5a12a60dc3d772.36151853.jpg
> >
> > If there is space the bar is static on the top right of the screen, if
> > there is not a wide enough gutter then it inlines at the top right of the
> > content.
>
> It seems this is broken (overlaps a lot of content - just by luck the
> content
> doesn't have long enough lines there to be hidden):
>
>   https://www.enlightenment.org/develop/api/class/efl/object
>
>   http://www.enlightenment.org/ss/e-5a14c363eec9d0.43575629.png
>
> It shouldn't "gutter" IMHO in this case either like on mobile like
> displays. I
> think you need a better solution. Most of that ToC IMHO is not useful while
> reading reference docs. Especially the Tutorials, Setup and APIs. Tutorials
> there is hopefully going to expand to 100's of items  making this pretty
> pointless. The Page Contents is the useful part as a "jump to this
> section". I
> assume for now most of that is "sample content" and will be reconsidered in
> future?
>
> I am thinking this should really just be a dropdown menu like Options etc.
> perhaps displayed by default? At least so I can hide it and read the
> content
> underneath?
>
> > It appears when there are 3 or more headings at level 2 and 3 - that
> means
> > we ignore top level headings (usually a page title) and expand 1 level if
> > the current top level area has child elements. Most of this is the ToC
> > plugin in dokuwiki and works quite well.
> >
> > Comments welcome, plenty of opportunity to adapt it to suit our style.
> > Andy
> >
> > On Wed, 8 Nov 2017 at 07:27 Carsten Haitzler 
> wrote:
> >
> > > On Tue, 07 Nov 2017 15:59:24 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > The amount of space it takes up is a stylistic issue - our template
> > > > explicitly reserves 1/4 of the screen for a ToC which is clearly not
> a
> > > > requirement.
> > >
> > > that was my major thing about it. stylistic. :) also the original css
> for
> > > it
> > > was a bit blergh and i didn't feel like fixing it up to be nicer so
> > > removing was
> > > less work. that's why i didnt do the TOC though. if you're going to do
> > > one...
> > > do it well. :)
> > >
> > > > Additionally of concern is that many of our pages (specifically the
> > > program
> > > > guide) have (manually entered) contents areas that are within the
> page
> > > > content.
> > > >
> https://www.enlightenment.org/develop/legacy/program_guide/eina/arrays
> > >
> > > That's kind of odd... I'd just remove it IMHO... :)
> > >
> > > > As part of this documentation effort we are seeing navigation as an
> area
> > > in
> > > > which we are significantly lacking so I think we can spend some time
> > > fixing
> > > > it.
> > > > I am a little unsure as to whether the main objection here is that
> we see
> > > > ToC as a bad thing or if we just did not find a way to include it
> neatly
> > > in
> > > > our layout.
> > >
> > > a little of the first but mostly the second. if you need a TOC because
> the
> > > page
> > > is so big ... i kind of think it should be split up... :)
> > >
> > > > If it were possible to make it well presented would people be
> generally
> > > in
> > > > 

Re: [E-devel] Git Feature/ Proposal

[Carsten Haitzler]

On Wed, 22 Nov 2017 08:12:13 + Andrew Williams  said:

> Can we instead ask people to pull master into their branch before asking
> for review / merging it up to master? That’s pretty common practice - in
> fact for a long lived branch I would expect that to happen on a regular
> basis.

That would be at a minimum.

> Andy
> On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André  wrote:
> 
> > My problem is that those branches won't be in sync with master.
> > This will lead to merge conflicts. I am these days reviewing a lot of work
> > done in dev branches or phab patches and it almost never applies nicely on
> > master, because the interfaces change.
> > A lot of work is done in branches (model, c#, eo widgets, ...) and those
> > tasks are both long term and involve more than a single dev. They require
> > constant rebasing on master or the final rebase will be a nightmare. Right
> > now this is done by people pulling other devs branches, and then rebasing
> > onto master in their own dev branch.
> >
> > Rewriting history on a shared branch has major downsides too. No problem
> > for dev branches as there's only one committer, but anyone pulling a
> > rewritten history will endure pain.
> >
> > Honestly I don't have a solution.
> >
> > It's a move in the right direction, but I'm not sure it's solving the
> > problems I'm facing :(
> >
> >
> >
> > 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
> >
> > > Only problem would be the commit emails being resent (because
> > > technically they are new commits). One can mitigate that by first
> > > pushing them to a dev branch. Commits there have first been there
> > > don't trigger emails.
> > >
> > > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> > >  wrote:
> > > > In the issue where a significant rebase against master is necessary
> > then
> > > > it's trivial enough to either push to a new feature branch or delete
> > and
> > > > re-create the existing branch.
> > > >
> > > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> > > >
> > > >> As Mike said, the rebase/sync to master is being done locally before
> > > >> the merge. If you are talking about keeping this branch in sync with
> > > >> master constantly while developing, yes it's a problem. But I guess
> > > >> it's not intended for long term features.
> > > >>
> > > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> > > >>  wrote:
> > > >> > I don't see a difference in the merge process? A feature branch
> > > should be
> > > >> > treated exactly the same as master; the only difference is that
> > it's a
> > > >> > branch which people must specifically pull in order to use instead
> > of
> > > >> being
> > > >> > master.
> > > >> >
> > > >> > When merging, you can either do a regular rebase/merge as in the git
> > > >> > practices documentation or you can choose to rebase/squash on the
> > > >> branched
> > > >> > commits prior to pushing the merge. There is no rewriting within the
> > > >> > branch, but you can still rewrite anything which has not been pushed
> > > to
> > > >> > master just prior to pushing it to master.
> > > >> >
> > > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> > > j...@videolan.org>
> > > >> > wrote:
> > > >> >
> > > >> >> Hey,
> > > >> >>
> > > >> >> If we can't rewrite history on those branches (rebase and push -f),
> > > how
> > > >> >> should we proceed with the merge to/from master?
> > > >> >> Usually when we merge a branch to master, we rebase it on top of
> > > master
> > > >> >> first and then rebase. That's how our history remains linear and
> > > simple.
> > > >> >>
> > > >> >> What's the idea here? I wonder.
> > > >> >>
> > > >> >> Thanks for implementing this btw,
> > > >> >>
> > > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> > > >> >>
> > > >> >> > I'm not sure about jenkins, that's Stefan's role.
> > > >> >> >
> > > >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> > > >> >> > especially mentioning probies when you say "everyone can push
> > to".
> > > >> >> >
> > > >> >> > --
> > > >> >> > Tom.
> > > >> >> >
> > > >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> > > >> >> >  wrote:
> > > >> >> > > I've added all the necessary info to the documentation at
> > > >> >> > >
> > > >> >>
> > > >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> > > Feature_Branches
> > > >> >> > >
> > > >> >> > > If the jenkins concept is not possible then feel free to
> > remove,
> > > but
> > > >> >> the
> > > >> >> > > rest should be in line with what we want.
> > > >> >> > >
> > > >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
> > > wrote:
> > > >> >> > >
> > > >> >> > >> So what has been decided? What should I do? I need specs,
> > > >> preferably
> > > >> >> > >> already added to the git wiki page 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Carsten Haitzler]

On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher  said:

> Hi,
> 
> I confirm, I had to add the above in my build script :
> 
> sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log

 7:14PM ~/C/e/build ⎇ master > ls -al
total 4.4M
4.0K drwxr-xr-x  9 raster raster 4.0K Nov 22 15:36 ./
4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../
1.6M -rw-r--r--  1 raster raster 1.6M Nov 22 15:36 .ninja_deps
 64K -rw-r--r--  1 raster raster  61K Nov 22 15:36 .ninja_log

written not as root. (make ninja install was as root). ... ?

> On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> > Hi,
> > 
> > Compiling as root may be a bad thing but mike is right, ninja install hits
> > log files and other - some times causing root ownership. I have seen it
> > occasionally myself and have had to either delete the build tree or chown
> > it to myself.
> > 
> > Perhaps this is a bug we should be reporting but in the meantime our docs
> > should cover it somehow.
> > 
> > Andy
> > On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler  wrote:
> > 
> > > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> > >  said:
> > >
> > > > The wording is intentional. The meson build has a tendency to touch
> > > > build files during the install phase (which must be run as root to
> > > > install to
> > > the
> > > > base system), meaning that failure to use sudo during general build will
> > > > fail for subsequent builds anyway due to permissions errors when
> > > attempting
> > > > to modify root-owned files.
> > >
> > > i have never had a permission error after a "sudo ninja install" to just
> > > run
> > > ninja as me to rebuild whatever changed. it's just the gmo files (and
> > > install
> > > log which obviously is written as root) from gettext... and they are only
> > > re-generated by root so ... root overwrites root files. you can delete
> > > these
> > > files because they are in a directory owned by you (the user).
> > >
> > > so where is the actual permission problem? a ninja && sudo ninja install
> > > will
> > > succeed without permission problems (see above). you as a user can delete
> > > the
> > > effected files too.
> > >
> > > but suggestion people compile as root is a bad idea.
> > >
> > > ???
> > >
> > > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler 
> > > > wrote:
> > > >
> > > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > > >  said:
> > > > >
> > > > > > Issues had been found at an inconvenient time during review, so I
> > > left
> > > > > the
> > > > > > branch unmerged so that someone could either push while I was gone
> > > or I
> > > > > > could push when I returned.
> > > > >
> > > > > I saw you pushed now. so we know the status. This also clears up the
> > > build
> > > > > system state. I guess I should ensure it's documented. I see README
> > > > > changed but
> > > > > i am not sure it's correct as it's going to do a build as root... i'll
> > > deal
> > > > > with it. :)
> > > > >
> > > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler <
> > > ras...@rasterman.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > > > > a...@andywilliams.me>
> > > > > > > said:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > As the autotool/Makefiles are still in place I fixed the build
> > > for
> > > > > users
> > > > > > > > not yet using the E meson build.
> > > > > > >
> > > > > > > i was assuming autotools was dead - mike did say he'd push his
> > > > > autotools
> > > > > > > removal branch "in a day or 2 if no issues"... that about 1-2
> > > > > > > weeks
> > > > > back. i
> > > > > > > didn't see it happen and didn't hear of issues...
> > > > > > >
> > > > > > > are there any? I'd consider merging his branch to remove autofoo
> > > > > > > at
> > > > > this
> > > > > > > point.
> > > > > > > If meson has issues it should be tested and they should be fixed.
> > > > > > >
> > > > > > > > Andy
> > > > > > > >
> > > > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler <
> > > ras...@rasterman.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > raster pushed a commit to branch master.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > > >
> > > > > > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > > > > > Date:   Fri Nov 17 12:17:42 2017 +0900
> > > > > > > > >
> > > > > > > > > music-control - install properly with meson build with
> > > > > > > > > icon
> > > > > > > > >
> > > > > > > > > @fix
> > > > > > > > > ---
> > > > > > > > >  ...-module-music_control.edj => e-module-music-control.edj} |
> > > Bin
> > > > > > > > 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Carsten Haitzler]

On Wed, 22 Nov 2017 08:18:54 + Andrew Williams  said:

> Hi,
> 
> Compiling as root may be a bad thing but mike is right, ninja install hits
> log files and other - some times causing root ownership. I have seen it
> occasionally myself and have had to either delete the build tree or chown
> it to myself.
> 
> Perhaps this is a bug we should be reporting but in the meantime our docs
> should cover it somehow.

It's not "on occasion" that they are written to. they are ALWAYS written to.
the *.gmo files in po/ and the install log. as the owner of the parent dir, the
user is allowed to delete these so it shouldn't be a problem.

but suggestion people compile as root is a pretty bad idea. compiling as user
then installing as root i don't see how it can create problems. the same files
(installlog and gmo files) are ONLY overwritten again when you do a make
install - as root with sudo.

unless you are installing as a user to a destdir or something ... then you may
have issues.

> Andy
> On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler  wrote:
> 
> > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> >  said:
> >
> > > The wording is intentional. The meson build has a tendency to touch build
> > > files during the install phase (which must be run as root to install to
> > the
> > > base system), meaning that failure to use sudo during general build will
> > > fail for subsequent builds anyway due to permissions errors when
> > attempting
> > > to modify root-owned files.
> >
> > i have never had a permission error after a "sudo ninja install" to just
> > run
> > ninja as me to rebuild whatever changed. it's just the gmo files (and
> > install
> > log which obviously is written as root) from gettext... and they are only
> > re-generated by root so ... root overwrites root files. you can delete
> > these
> > files because they are in a directory owned by you (the user).
> >
> > so where is the actual permission problem? a ninja && sudo ninja install
> > will
> > succeed without permission problems (see above). you as a user can delete
> > the
> > effected files too.
> >
> > but suggestion people compile as root is a bad idea.
> >
> > ???
> >
> > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler 
> > > wrote:
> > >
> > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > >  said:
> > > >
> > > > > Issues had been found at an inconvenient time during review, so I
> > left
> > > > the
> > > > > branch unmerged so that someone could either push while I was gone
> > or I
> > > > > could push when I returned.
> > > >
> > > > I saw you pushed now. so we know the status. This also clears up the
> > build
> > > > system state. I guess I should ensure it's documented. I see README
> > > > changed but
> > > > i am not sure it's correct as it's going to do a build as root... i'll
> > deal
> > > > with it. :)
> > > >
> > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > wrote:
> > > > >
> > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > > > a...@andywilliams.me>
> > > > > > said:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > As the autotool/Makefiles are still in place I fixed the build
> > for
> > > > users
> > > > > > > not yet using the E meson build.
> > > > > >
> > > > > > i was assuming autotools was dead - mike did say he'd push his
> > > > autotools
> > > > > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks
> > > > back. i
> > > > > > didn't see it happen and didn't hear of issues...
> > > > > >
> > > > > > are there any? I'd consider merging his branch to remove autofoo at
> > > > this
> > > > > > point.
> > > > > > If meson has issues it should be tested and they should be fixed.
> > > > > >
> > > > > > > Andy
> > > > > > >
> > > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > raster pushed a commit to branch master.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > >
> > > > > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > > > > Date:   Fri Nov 17 12:17:42 2017 +0900
> > > > > > > >
> > > > > > > > music-control - install properly with meson build with icon
> > > > > > > >
> > > > > > > > @fix
> > > > > > > > ---
> > > > > > > >  ...-module-music_control.edj => e-module-music-control.edj} |
> > Bin
> > > > > > > >  src/modules/music-control/meson.build
> >  |   2
> > > > --
> > > > > > > >  src/modules/music-control/module.desktop
> > |   2
> > > > +-
> > > > > > > >  3 files changed, 1 insertion(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git
> > 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Jérémy Zurcher]

Hi,

I confirm, I had to add the above in my build script :

sudo -S chown $USER $BUILD_DIR/.ninja_deps $BUILD_DIR/.ninja_log


On Wednesday 22 November 2017  08:18, Andrew Williams wrote :
> Hi,
> 
> Compiling as root may be a bad thing but mike is right, ninja install hits
> log files and other - some times causing root ownership. I have seen it
> occasionally myself and have had to either delete the build tree or chown
> it to myself.
> 
> Perhaps this is a bug we should be reporting but in the meantime our docs
> should cover it somehow.
> 
> Andy
> On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler  wrote:
> 
> > On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
> >  said:
> >
> > > The wording is intentional. The meson build has a tendency to touch build
> > > files during the install phase (which must be run as root to install to
> > the
> > > base system), meaning that failure to use sudo during general build will
> > > fail for subsequent builds anyway due to permissions errors when
> > attempting
> > > to modify root-owned files.
> >
> > i have never had a permission error after a "sudo ninja install" to just
> > run
> > ninja as me to rebuild whatever changed. it's just the gmo files (and
> > install
> > log which obviously is written as root) from gettext... and they are only
> > re-generated by root so ... root overwrites root files. you can delete
> > these
> > files because they are in a directory owned by you (the user).
> >
> > so where is the actual permission problem? a ninja && sudo ninja install
> > will
> > succeed without permission problems (see above). you as a user can delete
> > the
> > effected files too.
> >
> > but suggestion people compile as root is a bad idea.
> >
> > ???
> >
> > > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler 
> > > wrote:
> > >
> > > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > > >  said:
> > > >
> > > > > Issues had been found at an inconvenient time during review, so I
> > left
> > > > the
> > > > > branch unmerged so that someone could either push while I was gone
> > or I
> > > > > could push when I returned.
> > > >
> > > > I saw you pushed now. so we know the status. This also clears up the
> > build
> > > > system state. I guess I should ensure it's documented. I see README
> > > > changed but
> > > > i am not sure it's correct as it's going to do a build as root... i'll
> > deal
> > > > with it. :)
> > > >
> > > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > wrote:
> > > > >
> > > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > > > a...@andywilliams.me>
> > > > > > said:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > As the autotool/Makefiles are still in place I fixed the build
> > for
> > > > users
> > > > > > > not yet using the E meson build.
> > > > > >
> > > > > > i was assuming autotools was dead - mike did say he'd push his
> > > > autotools
> > > > > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks
> > > > back. i
> > > > > > didn't see it happen and didn't hear of issues...
> > > > > >
> > > > > > are there any? I'd consider merging his branch to remove autofoo at
> > > > this
> > > > > > point.
> > > > > > If meson has issues it should be tested and they should be fixed.
> > > > > >
> > > > > > > Andy
> > > > > > >
> > > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler <
> > ras...@rasterman.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > raster pushed a commit to branch master.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > >
> > > > > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > > > > Date:   Fri Nov 17 12:17:42 2017 +0900
> > > > > > > >
> > > > > > > > music-control - install properly with meson build with icon
> > > > > > > >
> > > > > > > > @fix
> > > > > > > > ---
> > > > > > > >  ...-module-music_control.edj => e-module-music-control.edj} |
> > Bin
> > > > > > > >  src/modules/music-control/meson.build
> >  |   2
> > > > --
> > > > > > > >  src/modules/music-control/module.desktop
> > |   2
> > > > +-
> > > > > > > >  3 files changed, 1 insertion(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git
> > a/src/modules/music-control/e-module-music_control.edj
> > > > > > > > b/src/modules/music-control/e-module-music-control.edj
> > > > > > > > similarity index 100%
> > > > > > > > rename from
> > src/modules/music-control/e-module-music_control.edj
> > > > > > > > rename to src/modules/music-control/e-module-music-control.edj
> > > > > > > > diff --git a/src/modules/music-control/meson.build
> > > > > > > > b/src/modules/music-control/meson.build
> > > > > > 

Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon

[Andrew Williams]

Hi,

Compiling as root may be a bad thing but mike is right, ninja install hits
log files and other - some times causing root ownership. I have seen it
occasionally myself and have had to either delete the build tree or chown
it to myself.

Perhaps this is a bug we should be reporting but in the meantime our docs
should cover it somehow.

Andy
On Wed, 22 Nov 2017 at 00:19, Carsten Haitzler  wrote:

> On Tue, 21 Nov 2017 16:37:09 + Mike Blumenkrantz
>  said:
>
> > The wording is intentional. The meson build has a tendency to touch build
> > files during the install phase (which must be run as root to install to
> the
> > base system), meaning that failure to use sudo during general build will
> > fail for subsequent builds anyway due to permissions errors when
> attempting
> > to modify root-owned files.
>
> i have never had a permission error after a "sudo ninja install" to just
> run
> ninja as me to rebuild whatever changed. it's just the gmo files (and
> install
> log which obviously is written as root) from gettext... and they are only
> re-generated by root so ... root overwrites root files. you can delete
> these
> files because they are in a directory owned by you (the user).
>
> so where is the actual permission problem? a ninja && sudo ninja install
> will
> succeed without permission problems (see above). you as a user can delete
> the
> effected files too.
>
> but suggestion people compile as root is a bad idea.
>
> ???
>
> > On Mon, Nov 20, 2017 at 8:14 PM Carsten Haitzler 
> > wrote:
> >
> > > On Mon, 20 Nov 2017 15:04:48 + Mike Blumenkrantz
> > >  said:
> > >
> > > > Issues had been found at an inconvenient time during review, so I
> left
> > > the
> > > > branch unmerged so that someone could either push while I was gone
> or I
> > > > could push when I returned.
> > >
> > > I saw you pushed now. so we know the status. This also clears up the
> build
> > > system state. I guess I should ensure it's documented. I see README
> > > changed but
> > > i am not sure it's correct as it's going to do a build as root... i'll
> deal
> > > with it. :)
> > >
> > > > On Sun, Nov 19, 2017 at 6:56 PM Carsten Haitzler <
> ras...@rasterman.com>
> > > > wrote:
> > > >
> > > > > On Sun, 19 Nov 2017 13:05:06 + Andrew Williams <
> > > a...@andywilliams.me>
> > > > > said:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > As the autotool/Makefiles are still in place I fixed the build
> for
> > > users
> > > > > > not yet using the E meson build.
> > > > >
> > > > > i was assuming autotools was dead - mike did say he'd push his
> > > autotools
> > > > > removal branch "in a day or 2 if no issues"... that about 1-2 weeks
> > > back. i
> > > > > didn't see it happen and didn't hear of issues...
> > > > >
> > > > > are there any? I'd consider merging his branch to remove autofoo at
> > > this
> > > > > point.
> > > > > If meson has issues it should be tested and they should be fixed.
> > > > >
> > > > > > Andy
> > > > > >
> > > > > > On Fri, 17 Nov 2017 at 03:19 Carsten Haitzler <
> ras...@rasterman.com>
> > > > > wrote:
> > > > > >
> > > > > > > raster pushed a commit to branch master.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> http://git.enlightenment.org/core/enlightenment.git/commit/?id=f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > >
> > > > > > > commit f4d2d02ba0f15b7f36e7de61141ff88c145f5630
> > > > > > > Author: Carsten Haitzler (Rasterman) 
> > > > > > > Date:   Fri Nov 17 12:17:42 2017 +0900
> > > > > > >
> > > > > > > music-control - install properly with meson build with icon
> > > > > > >
> > > > > > > @fix
> > > > > > > ---
> > > > > > >  ...-module-music_control.edj => e-module-music-control.edj} |
> Bin
> > > > > > >  src/modules/music-control/meson.build
>  |   2
> > > --
> > > > > > >  src/modules/music-control/module.desktop
> |   2
> > > +-
> > > > > > >  3 files changed, 1 insertion(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git
> a/src/modules/music-control/e-module-music_control.edj
> > > > > > > b/src/modules/music-control/e-module-music-control.edj
> > > > > > > similarity index 100%
> > > > > > > rename from
> src/modules/music-control/e-module-music_control.edj
> > > > > > > rename to src/modules/music-control/e-module-music-control.edj
> > > > > > > diff --git a/src/modules/music-control/meson.build
> > > > > > > b/src/modules/music-control/meson.build
> > > > > > > index 996b4196f..a84f5ea8e 100644
> > > > > > > --- a/src/modules/music-control/meson.build
> > > > > > > +++ b/src/modules/music-control/meson.build
> > > > > > > @@ -18,5 +18,3 @@ src += custom_target('gen-dbus',
> > > > > > >   command: [eldbus_codegen, '@INPUT@',
> '-O',
> > > > > '@OUTDIR@
> > > > > > > '],
> > > > > > >   output : created_file
> > > > > > >  )
> > > > > > > -
> > 

Re: [E-devel] Git Feature/ Proposal

[Andrew Williams]

Can we instead ask people to pull master into their branch before asking
for review / merging it up to master? That’s pretty common practice - in
fact for a long lived branch I would expect that to happen on a regular
basis.

Andy
On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André  wrote:

> My problem is that those branches won't be in sync with master.
> This will lead to merge conflicts. I am these days reviewing a lot of work
> done in dev branches or phab patches and it almost never applies nicely on
> master, because the interfaces change.
> A lot of work is done in branches (model, c#, eo widgets, ...) and those
> tasks are both long term and involve more than a single dev. They require
> constant rebasing on master or the final rebase will be a nightmare. Right
> now this is done by people pulling other devs branches, and then rebasing
> onto master in their own dev branch.
>
> Rewriting history on a shared branch has major downsides too. No problem
> for dev branches as there's only one committer, but anyone pulling a
> rewritten history will endure pain.
>
> Honestly I don't have a solution.
>
> It's a move in the right direction, but I'm not sure it's solving the
> problems I'm facing :(
>
>
>
> 2017-11-22 3:43 GMT+09:00 Tom Hacohen :
>
> > Only problem would be the commit emails being resent (because
> > technically they are new commits). One can mitigate that by first
> > pushing them to a dev branch. Commits there have first been there
> > don't trigger emails.
> >
> > On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
> >  wrote:
> > > In the issue where a significant rebase against master is necessary
> then
> > > it's trivial enough to either push to a new feature branch or delete
> and
> > > re-create the existing branch.
> > >
> > > On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen  wrote:
> > >
> > >> As Mike said, the rebase/sync to master is being done locally before
> > >> the merge. If you are talking about keeping this branch in sync with
> > >> master constantly while developing, yes it's a problem. But I guess
> > >> it's not intended for long term features.
> > >>
> > >> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
> > >>  wrote:
> > >> > I don't see a difference in the merge process? A feature branch
> > should be
> > >> > treated exactly the same as master; the only difference is that
> it's a
> > >> > branch which people must specifically pull in order to use instead
> of
> > >> being
> > >> > master.
> > >> >
> > >> > When merging, you can either do a regular rebase/merge as in the git
> > >> > practices documentation or you can choose to rebase/squash on the
> > >> branched
> > >> > commits prior to pushing the merge. There is no rewriting within the
> > >> > branch, but you can still rewrite anything which has not been pushed
> > to
> > >> > master just prior to pushing it to master.
> > >> >
> > >> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <
> > j...@videolan.org>
> > >> > wrote:
> > >> >
> > >> >> Hey,
> > >> >>
> > >> >> If we can't rewrite history on those branches (rebase and push -f),
> > how
> > >> >> should we proceed with the merge to/from master?
> > >> >> Usually when we merge a branch to master, we rebase it on top of
> > master
> > >> >> first and then rebase. That's how our history remains linear and
> > simple.
> > >> >>
> > >> >> What's the idea here? I wonder.
> > >> >>
> > >> >> Thanks for implementing this btw,
> > >> >>
> > >> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen :
> > >> >>
> > >> >> > I'm not sure about jenkins, that's Stefan's role.
> > >> >> >
> > >> >> > Anyhow, pushed the changes according to the wiki. Please consider
> > >> >> > especially mentioning probies when you say "everyone can push
> to".
> > >> >> >
> > >> >> > --
> > >> >> > Tom.
> > >> >> >
> > >> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
> > >> >> >  wrote:
> > >> >> > > I've added all the necessary info to the documentation at
> > >> >> > >
> > >> >>
> > >> https://www.enlightenment.org/contrib/devs/git-guide.md#
> > Feature_Branches
> > >> >> > >
> > >> >> > > If the jenkins concept is not possible then feel free to
> remove,
> > but
> > >> >> the
> > >> >> > > rest should be in line with what we want.
> > >> >> > >
> > >> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen 
> > wrote:
> > >> >> > >
> > >> >> > >> So what has been decided? What should I do? I need specs,
> > >> preferably
> > >> >> > >> already added to the git wiki page so there are docs for this
> > >> thing.
> > >> >> > >>
> > >> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
> > >> >> ras...@rasterman.com
> > >> >> > >
> > >> >> > >> wrote:
> > >> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> > >> >> > >> >  said:
> > >> >> > >> >
> > >> >> > >>