Re: [E-devel] Keyboard sequence to escape Terminology from Enlightenment top bar toggled Fullscreen option

[Ross Vandegrift]

On Wed, Feb 07, 2024 at 10:51:31PM -0800, jose@metztli.com wrote:
> Is there a way to exit Enlightenment/Terminology Fullscreen without closing
> Terminology app itself?

F11 does that for me - though I don't see any key binding for
Window:State -> Fullscreen Mode Toggle in Key Bindings.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl test suite timeouts under `ninja test`

[Ross Vandegrift]

On Tue, Jan 09, 2024 at 08:35:00AM -0800, Ross Vandegrift wrote:
> Here's the difference:
> - `bash -c /bin/true` directly execs /bin/true without a fork
> - `dash -c /bin/true` always fork & execs
[snip]
> (Side note: bash's lack of fork is surprising, but I'm surely ignorant of
> some details.)

Found a note in bash's CHANGES [1] file about this:
| b. Bash attempts to optimize the number of times it forks when executing
|commands in subshells and from `bash -c'.

This was a new feature in 5.1-alpha.

Ross

[1] https://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES#n1025


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl test suite timeouts under `ninja test`

[Ross Vandegrift]

On Tue, Jan 09, 2024 at 08:16:00AM +, Carsten Haitzler wrote:
> > So eina_suite.c gets the wrong pid from fork().  In a simple standalone
> > program, fork() behaves as expected.
> 
> now a returned pid of 0 ... THAT IS WRONG! well unless its inside the child.
> the parent should get -1 for a failure or > 0 for the child pid. the child 
> gets
> 0 ... but see below

Yea, I was printing in the parent and child, but my message didn't
indicate that.  Nothing bad going on there.

> > I'm going to compare the arch & debian check packages for any suspicious
> > differences.  And maybe walk through more carefully with gdb.  But I'm out 
> > of
> > time tonight.
> 
> Yeah - I see the problem in debian SID (this is on aarch64 btw) ... but it
> totally smells of a check bug as above. just a cursory glance tells me that
> something is wrong over there - if check is sitting and waiting on test suite
> procs that have already exited/gone...

I played a bit more with strace - it's a bashism in efl_check.h.  If I
switch the code at [1] to use /bin/bash, then it works for me.  I bet
Arch has /bin/sh linked to bash; on Debian, /bin/sh is dash.

Here's the difference:
- `bash -c /bin/true` directly execs /bin/true without a fork
- `dash -c /bin/true` always fork & execs

Looking at efl_check.h, eina_suite does:
- fork & exec /bin/sh -c /path/to/timeout

That means the sequence is:
- on bash: fork, exec, exec
- on dash: fork, exec, fork, exec

So there's no exotic bug with libc/linux/etc - fork works fine, there's
just an extra one.  I'd guess that strace -f and adding a pipe changes
the fork order, and that's why they tend to trigger this.

(Side note: bash's lack of fork is surprising, but I'm surely ignorant of
some details.)

Ross

[1] - 
https://git.enlightenment.org/enlightenment/efl/src/commit/248d62bf5e13ca8800a73b6cf3e8759443468282/src/tests/efl_check.h#L378


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl test suite timeouts under `ninja test`

[Ross Vandegrift]

On Mon, Jan 08, 2024 at 11:08:55PM +, Carsten Haitzler wrote:
> try run the above eina test suite and pipe to something that makes it
> timeout... and strace it - or gdb attach to it and find out where it's 
> sitting?
> it should complete in < 1 sec so launch and immediately try and strace and/or
> gdb attach and find out where it's at - if it is still around.
> 
> is somehow a forked child not coming back that it expects to... ?

Yea, it's something like this.  I found out it hangs for exactly 60s, which
lead me to timeout.c.  I also learned strace -f triggers the issue.  CK_FORK=no
fixes the hang as well.

I added debug printfs to efl_check.h and timeout.c - when eina_suite tries to
kill timeout, it kills the wrong pid:

  $ ./build/src/tests/eina/eina_suite fp
  Running suite(s): eina_init_module
  100%: Checks: 0, Failures: 0, Errors: 0
   efl_check forked timeout: 296393<-
   efl_check forked timeout: 0
  Running suite(s): Eina
   timeout.c my pid: 296396<-
  Max delta(multiplication): 0.007627 (0.061668%)
  Max delta(division): 0.000173 (0.740211%)
  100%: Checks: 4, Failures: 0, Errors: 0
   efl_check killing timeout child: 296393
   efl_check cleared timeout_pid: 0

So eina_suite.c gets the wrong pid from fork().  In a simple standalone
program, fork() behaves as expected.

I'm going to compare the arch & debian check packages for any suspicious
differences.  And maybe walk through more carefully with gdb.  But I'm out of
time tonight.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl test suite timeouts under `ninja test`

[Ross Vandegrift]

On Mon, Jan 08, 2024 at 06:53:09PM +, Carsten Haitzler wrote:
> i'm going to guess something is missing in the env? missing hmm dbus daemon?
> something else? some env missing like xdg runtime dir ... or something? but
> eina test suite should not need all of that sho it shouldnt be timing out - if
> you just run e.g. the eina suite e.g.
> 
> ./src/tests/eina/eina_suite
> 
> what happens? it should complete in almost no time (like a fraction of a
> second)...

Yea, on their own they run fine - as long as I don't pipe the output to
another program (see my original message for more of what happens in
that case)

I'm running in a normal X session, so dbus should be fine.  I have check
0.15.2, which looks like the newest.  I'll keep digging.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] efl test suite timeouts under `ninja test`

[Ross Vandegrift]

Hello,

It's been a while since I used the EFL test suite, not sure if I'm forgetting
something or if I've found a problem.

On 1.27.0, `ninja test` runs into a bunch of timeouts:

Summary of Failures:

20/38 eina  TIMEOUT 30.11s
21/38 eo-suite  TIMEOUT 30.10s
22/38 eo-suite-dbg  TIMEOUT 30.10s
23/38 eo-suite-fallback TIMEOUT 30.09s
24/38 efl-suite TIMEOUT 30.04s
25/38 emile-suite   TIMEOUT 30.04s
26/38 eet-suite TIMEOUT 30.03s
27/38 eldbus-suite  TIMEOUT 30.03s
28/38 ecore-suite   TIMEOUT 30.02s
29/38 efl-app   TIMEOUT 30.02s
30/38 ecore_con-suite   TIMEOUT 30.07s
31/38 eeze-suiteTIMEOUT 30.06s
32/38 efreet-suite  TIMEOUT 30.01s
33/38 edje-suiteTIMEOUT 30.01s
34/38 elementary-suite  TIMEOUT 30.02s
35/38 efl-ui-suite  TIMEOUT 30.02s   (exit status 255 or 
signal 127 SIGinvalid)
36/38 evas-suiteTIMEOUT 60.01s
38/38 efl_ui_spec-suite TIMEOUT 60.01s

But at least some of the individual test suites succeed:

$ EFL_RUN_IN_TREE=1 ./build/src/tests/evas/evas_suite &> out
$ grep Failures out
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 2, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 2, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 7, Failures: 0, Errors: 0
100%: Checks: 10, Failures: 0, Errors: 0
100%: Checks: 16, Failures: 0, Errors: 0
100%: Checks: 4, Failures: 0, Errors: 0
100%: Checks: 37, Failures: 0, Errors: 0
100%: Checks: 2, Failures: 0, Errors: 0
100%: Checks: 25, Failures: 0, Errors: 0


I'm redirecting to a file instead of a pipe - if I use a pipe, the test suite
hangs forever at the end.  Seems like this could be related?

$ EFL_RUN_IN_TREE=1 ./build/src/tests/evas/evas_suite 2>&1 | grep Failures
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 1, Failures: 0, Errors: 0
100%: Checks: 2, Failures: 0, Errors: 0
100%: Checks: 2, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 3, Failures: 0, Errors: 0
100%: Checks: 7, Failures: 0, Errors: 0
100%: Checks: 10, Failures: 0, Errors: 0
100%: Checks: 4, Failures: 0, Errors: 0
100%: Checks: 16, Failures: 0, Errors: 0
100%: Checks: 37, Failures: 0, Errors: 0
100%: Checks: 2, Failures: 0, Errors: 0
100%: Checks: 25, Failures: 0, Errors: 0<- never returns, but looks done

Thanks for any pointers,
Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E 0.25.1, emacs windows stop updating on virtual desktop change

[Ross Vandegrift]

On Sat, Jan 15, 2022 at 10:21:43PM -0800, Ross Vandegrift wrote:
> On Sat, Jan 15, 2022 at 11:40:52PM +, Carsten Haitzler wrote:
> > On Sat, 15 Jan 2022 14:18:11 -0800 Ross Vandegrift  said:
> > > After upgrading to E 0.25.1, emacs windows stop updating after a virtual
> > > desktop change.  They still respond to keyboard input.  Shade/unshade 
> > > fixes
> > > it.
> > 
> > emacs here doesn't seem to break - it's working just fine when i switch
> > desktops. perhaps your version? emacs 27.2 here? e will set netm state 
> > hidden -
> > perhaps emacs is mis-handling this?
> > 
> > 11:24PM ~ > xprop -id 0x182 | grep _NET_WM_STATE
> > _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN
> > 11:24PM ~ > xprop -id 0x182 | grep _NET_WM_STATE
> > 
> > e sets the property then removes it when you switch desktop back again.
> 
> Aha, I can only trigger the issue with GTK3 builds of emacs.  If I use
> Xaw/lucid it works normally.  27.2 is also affected - I'll file an emacs bug.

Just to close the loop on this: emacs is adding a new config option to adjust
it's visibility behavior in cases like this.  If you run into this issue, check
out the option 'x-set-frame-visibility-more-laxly'.  Full details at:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53298

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E 0.25.1, emacs windows stop updating on virtual desktop change

[Ross Vandegrift]

On Sat, Jan 15, 2022 at 11:40:52PM +, Carsten Haitzler wrote:
> On Sat, 15 Jan 2022 14:18:11 -0800 Ross Vandegrift  said:
> > After upgrading to E 0.25.1, emacs windows stop updating after a virtual
> > desktop change.  They still respond to keyboard input.  Shade/unshade fixes
> > it.
> 
> emacs here doesn't seem to break - it's working just fine when i switch
> desktops. perhaps your version? emacs 27.2 here? e will set netm state hidden 
> -
> perhaps emacs is mis-handling this?
> 
> 11:24PM ~ > xprop -id 0x182 | grep _NET_WM_STATE
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN
> 11:24PM ~ > xprop -id 0x182 | grep _NET_WM_STATE
> 
> e sets the property then removes it when you switch desktop back again.

Aha, I can only trigger the issue with GTK3 builds of emacs.  If I use
Xaw/lucid it works normally.  27.2 is also affected - I'll file an emacs bug.

Thanks,
Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E 0.25.1, emacs windows stop updating on virtual desktop change

[Ross Vandegrift]

On Sat, Jan 15, 2022 at 11:40:52PM +, Carsten Haitzler wrote:
> On Sat, 15 Jan 2022 14:18:11 -0800 Ross Vandegrift  said:
> > After upgrading to E 0.25.1, emacs windows stop updating after a virtual
> > desktop change.  They still respond to keyboard input.  Shade/unshade fixes
> > it.
> 
> emacs here doesn't seem to break - it's working just fine when i switch
> desktops. perhaps your version? emacs 27.2 here? e will set netm state hidden 
> -
> perhaps emacs is mis-handling this?

Hmmm, could be - I'm on 27.1, so it's possible this is a fixed issue in 27.2.
I'll give a shot.

Thanks for checking,
Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] E 0.25.1, emacs windows stop updating on virtual desktop change

[Ross Vandegrift]

Hello,

After upgrading to E 0.25.1, emacs windows stop updating after a virtual
desktop change.  They still respond to keyboard input.  Shade/unshade fixes it.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] efl test suite timeouts in 1.26?

[Ross Vandegrift]

On Tue, Jan 04, 2022 at 08:24:02AM +, Carsten Haitzler wrote:
> I don't see the timeouts here... this relies on check as the infra - and check
> does all the stuff before a fork happens to run the actual test... and check 
> is
> a local system dependency... so something either really screwy about your os,
> build env or check?

I played with this some more - it's related to check's forking on debian
unstable.  The issue doesn't happen in debian stable, or if CK_FORK=no.  check
is at 0.15.2 in both though.

> [0/1] Running all tests.
>  1/39 eo-mixins OK   0.09s
>  2/39 eo-mixins-dbg OK   0.09s
>  3/39 eo-interface  OK   0.09s
>  4/39 eo-interface-dbg  OK   0.08s
>  5/39 eo-function-overrides OK   0.08s
>  6/39 eo-function-overrides-dbg OK   0.08s
>  7/39 eo-composite-objects  OK   0.08s
>  8/39 eo-composite-objects-dbg  OK   0.08s
>  9/39 eo-children   OK   0.07s
> ... etc.

Once past the timeouts, I am seeing a few things that could be issues:

$ CK_VERBOSITY=verbose ./src/tests/eet/eet_suite "Eet File"
Running suite(s): Eet
50%: Checks: 4, Failures: 0, Errors: 2
../src/tests/eet/eet_test_file.c:117:P:Eet File:eet_test_file_simple_write:0: 
Passed
../src/tests/eet/eet_test_file.c:175:E:Eet File:eet_test_file_data:0: (after 
this point) Received signal 11 (Segmentation fault)
../src/tests/eet/eet_test_file.c:371:P:Eet File:eet_test_file_data_dump:0: 
Passed
../src/tests/eet/eet_test_file.c:419:E:Eet File:eet_test_file_fp:0: (after this 
point) Received signal 11 (Segmentation fault)

$ CK_VERBOSITY=vebose ./src/tests/elementary/elementary_suite 2> /dev/null | 
grep :F:
../src/tests/elementary/suite_helpers.c:604:F:elm_check:elm_test_check_callbacks:1:
 Assertion '*called == 0' failed: *called == 1, 0 == 0
../src/tests/elementary/elm_test_widget_focus.c:194:F:elm_widget_focus:elm_test_widget_focus_simple_widget:0:
 Assertion 'flag_focused == ((Eina_Bool)1)' failed: flag_focused == 0, 
((Eina_Bool)1) == 1

$ CK_VERBOSITY=verbose ./src/tests/elementary/efl_ui_suite 2> /dev/null | grep 
:F:
../src/tests/elementary/efl_ui_test_focus.c:454:F:efl_ui_focus:invalid_args_check:0:
 Assertion 'expect_error_start == ((Eina_Bool)1)' failed: expect_error_start == 
0, ((Eina_Bool)1) == 1

Haven't had time to dig further.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] efl test suite timeouts in 1.26?

[Ross Vandegrift]

Hello,

With 1.26, I'm seeing "ninja test" timeout on every single suite.  Except for
the actual failures & errors I'm seeing, running the individual binaries is
fine.  There seems to be something weird with forking - I hardcoded "do_fork =
0;" at src/tests/efl_check.h:359 and most of the timeouts are gone.

Sample comparison with default meson options:

  Summary of Failures:

  18/44 eo-suite  TIMEOUT 30.11s
  19/44 eo-suite-dbg  TIMEOUT 30.10s
  20/44 eo-suite-fallback TIMEOUT 30.09s
  21/44 eina  TIMEOUT 30.14s   killed by signal 15 
SIGTERM
  22/44 efl-suite TIMEOUT 30.01s
  23/44 emile-suite   TIMEOUT 30.01s
  24/44 eet-suite TIMEOUT 30.02s   exit status 1
  27/44 eldbus-suite  TIMEOUT 30.01s   killed by signal 15 
SIGTERM
  28/44 ecore-suite   TIMEOUT 30.04s
  29/44 efl-app   TIMEOUT 30.04s
  30/44 ecore_con-suite   TIMEOUT 30.03s
  31/44 eeze-suiteTIMEOUT 30.02s
  32/44 efreet-suite  TIMEOUT 30.01s
  33/44 edje-suiteTIMEOUT 30.01s
  37/44 elementary-suite  TIMEOUT 30.03s   (exit status 255 or 
signal 127 SIGinvalid)
  38/44 efl-ui-suite  TIMEOUT 30.03s   (exit status 255 or 
signal 127 SIGinvalid)
  39/44 eina_cxx-suiteTIMEOUT 30.03s
  40/44 evas-suiteTIMEOUT 60.02s
  41/44 eolian_cxx-suite  TIMEOUT 30.05s
  43/44 eldbus_cxx-suite  TIMEOUT 30.04s   (exit status 255 or 
signal 127 SIGinvalid)
  44/44 efl_ui_spec-suite TIMEOUT 60.02s
  
  
  Ok: 23
  Expected Fail:  0
  Fail:   0
  Unexpected Pass:0
  Skipped:0
  Timeout:21
  ... 
  $ time EFL_RUN_IN_TREE=1 ./src/tests/eina/eina_suite
  ...
  100%: Checks: 3, Failures: 0, Errors: 0
  100%: Checks: 11, Failures: 0, Errors: 0
  100%: Checks: 7, Failures: 0, Errors: 0
  100%: Checks: 9, Failures: 0, Errors: 0
  100%: Checks: 3, Failures: 0, Errors: 0
  100%: Checks: 7, Failures: 0, Errors: 0
  100%: Checks: 10, Failures: 0, Errors: 0
  100%: Checks: 3, Failures: 0, Errors: 0
  
  real  0m0.180s
  user  0m0.387s
  sys   0m0.469s
  $ echo $?
  0


Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Updated Python-efl Tutorial Codes

[Ross Vandegrift]

On Wed, Nov 10, 2021 at 10:17:08AM +0100, Davide Andrei wrote:
> Il giorno mar 9 nov 2021 alle ore 17:30 Ross Vandegrift 
> ha scritto:
> > I maintain the debian packages for enlightenment and efl.  I haven't
> > packaged python-efl mostly out of ignorance - I didn't know anyone
> > wanted it, and I don't know about any apps that use it.  So I can't say
> > it'll be high on my list, but if I find some time, I'll take a peek.
> >
> > Of course if you (or anyone else) is interested, there's good materials
> > on debian packaging python libraries.  I'd be happy to include that in
> > the team that handles efl/enlightenment, and help get it into debian.
> >
> 
> That would be awesome! I have zero experience in deb packaging,
> but I think that the bodylinux guys already have a good python-efl package.
> Can that one be useful?

Probably not - last I looked (which was years ago), bodhi never
published source packages for their debs.  So I can't even check if it
would be a Debian policy-compliant package.  If that's changed, I'd be
happy to take a look at the source package to see what'd need work.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Updated Python-efl Tutorial Codes

[Ross Vandegrift]

On Tue, Nov 09, 2021 at 01:16:30PM +0200, Joonas Niilola wrote:
> in general I personally hate installing software outside my
> distributions package manager. I believe you should try to make them
> into dpkg's, and aim to get these distributed through upstream ;)
> 
> Surely this way will get the work done, and get you started. But just a
> suggestion.

I maintain the debian packages for enlightenment and efl.  I haven't
packaged python-efl mostly out of ignorance - I didn't know anyone
wanted it, and I don't know about any apps that use it.  So I can't say
it'll be high on my list, but if I find some time, I'll take a peek.

Of course if you (or anyone else) is interested, there's good materials
on debian packaging python libraries.  I'd be happy to include that in
the team that handles efl/enlightenment, and help get it into debian.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Neon and 32 bit arm.

[Ross Vandegrift]

On Thu, Nov 12, 2020 at 10:50:50PM +1030, Simon Lees wrote:
> armv6 and some armv7 chips don't support neon, our current detection in
> meson causes openSUSE's 32bit arm builds to fail. Is this something we
> care about enough upstream to make the meson files better or should we
> just keep patching out 32bit arm for openSUSE.

Is it failing in edje_cc?  I had similar issues a while back with the
Debian packages, but -Dnative-arch-optimization=false seems to do the
trick now.

Some details in: https://phab.enlightenment.org/T6711

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 04/06: remove offline+presentation mode - this has confused people

[Ross Vandegrift]

On Sat, Oct 10, 2020 at 01:55:10PM +0100, Carsten Haitzler wrote:
> the solution for you might be as simple as an action that toggles blanking
> settings on/off rather than an added option with a second checkbox to worry
> about.

Yea, that sounds like it'd work great.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/enlightenment] master 04/06: remove offline+presentation mode - this has confused people

[Ross Vandegrift]

On Fri, Oct 09, 2020 at 08:00:53PM +0100, Carsten Haitzler wrote:
> you can just disable blanking... :) it is just a checkbox. :) presentation 
> mode
> was ANOTHER checkbox in addition to this so blanking would fail in 
> presentation
> mode was on and actually it mostly seems like e is buggy... until u remember
> presentation mode. simplifying to "just turn blanking off in blanking" is
> probably the simpler way to do this. :)

I also use it frequently and am sorry to see it go.  Presentation mode is nice
because it can be bound to a hotkey, or easily clicked right in a menu.  This
is great for video calls when I haven't used the keyboard or mouse much.
Opening settings will be more distracting from the conversation.  It'll be
fine, just more akward.

Ya, I forget to disable it sometimes.  But E reminds me next time I login.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment Foundation Libraries 1.25 Release

[Ross Vandegrift]

On Thu, Sep 24, 2020 at 01:19:26PM +0200, Stefan Schmidt wrote:
> On 24.09.20 11:03, Marcel Hollerbach wrote:
> > On 9/24/20 10:20 AM, Stefan Schmidt wrote:
> > > Very strange. I had no other reports about this and we are also
> > > building Debian 10.3 and Ubunutu 19.10 + 20.04 on our CI builds.
> > > Which are building fine.

A few things in the Debian packaging differ from upstream defaults - in this
case, it's probably having strict linking options in LDFLAGS:
  -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed

> > > Maybe Marcel has an idea?
> > 
> > Yeah, i accidently changed there something when i refactored things for
> > efl-one.
> > I just pushed abf0e9dffe35da8fa6e20055f53786b2adbec271, it should fix it
> > hopefully
> > (at least it restores the old state).
> 
> Thanks a lot!
> 
> Ross, Jose, could you please test the patch and confirm?
> If it fixes your issue I will make sure it lands in the future 1.25.1

Yes this helps, thanks Marcel - the same change is also needed in ecore_imf
scim and xim modules.  See below.

Ross


--- a/src/modules/ecore_imf/xim/meson.build
+++ b/src/modules/ecore_imf/xim/meson.build
@@ -2,7 +2,7 @@
   'ecore_imf_xim.c',
 ])

-mod_deps = [ecore, ecore_imf, ecore_input, ecore_x, ecore_x_deps, ecore_evas]
+mod_deps = [ecore, ecore_imf, ecore_input, ecore_x, ecore_x_ext_deps, 
ecore_evas]

 shared_module(mod_name,
 mod_src,
--- a/src/modules/ecore_imf/scim/meson.build
+++ b/src/modules/ecore_imf/scim/meson.build
@@ -9,7 +9,7 @@
   scim_dep = dependency('scim-1.0')
 endif

-mod_deps = [ecore, ecore_imf, ecore_x, ecore_x_deps, ecore_evas, scim_dep, 
dependency('glib-2.0')]
+mod_deps = [ecore, ecore_imf, ecore_x, ecore_x_ext_deps, ecore_evas, scim_dep, 
dependency('glib-2.0')]

 shared_module(mod_name,
 mod_src,



___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment Foundation Libraries 1.25 Release

[Ross Vandegrift]

On Wed, Sep 23, 2020 at 01:10:37PM +0200, Stefan Schmidt wrote:
> === Enlightenment Foundation Libraries 1.25 Release ===

Thanks Stefan!

I'm hitting a link failure in the software_x11 engine.  Looks like it's missing
a -lXext.  Log of error is below.  Could be something in 8e3606698e, but I
probably won't have time to dig in until next week.

Ross

cc  -o src/modules/evas/engines/software_x11/libsoftware_x11.so 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_engine.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_x_egl.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_swapbuf.c.o
 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_outbuf.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_buffer.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_color.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_main.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_swapper.c.o
 src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_image.c.o 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_dri_image.c.o
 -Wl,--as-needed -Wl,--allow-shlib-undefined -shared -fPIC -Wl,--start-group 
-Wl,-soname,libsoftware_x11.so -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden 
-O3 -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed 
src/lib/eina/libeina.so.1.25.0 src/lib/evas/libevas.so.1.25.0 
src/lib/ecore/libecore.so.1.25.0 src/lib/eo/libeo.so.1.25.0 
src/lib/efl/libefl.so.1.25.0 src/lib/ector/libector.so.1.25.0 
src/lib/emile/libemile.so.1.25.0 src/static_libs/libunibreak/liblibunibreak.a 
src/wayland_protocol/libwayland_protocol.a src/lib/eet/libeet.so.1.25.0 
src/lib/ecore_x/libecore_x.so.1.25.0 
src/lib/ecore_input/libecore_input.so.1.25.0 -pthread -lm -ldl 
/usr/lib/x86_64-linux-gnu/libluajit-5.1.so 
/usr/lib/x86_64-linux-gnu/libfreetype.so 
/usr/lib/x86_64-linux-gnu/libfontconfig.so 
/usr/lib/x86_64-linux-gnu/libfribidi.so 
/usr/lib/x86_64-linux-gnu/libharfbuzz.so 
/usr/lib/x86_64-linux-gnu/libwayland-client.so 
/usr/lib/x86_64-linux-gnu/libX11.so /usr/lib/x86_64-linux-gnu/libGLESv2.so 
/usr/lib/x86_64-linux-gnu/libEGL.so -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../../../../lib/eina:$ORIGIN/../../../../lib/evas:$ORIGIN/../../../../lib/eo:$ORIGIN/../../../../lib/ector:$ORIGIN/../../../../lib/efl:$ORIGIN/../../../../lib/emile:$ORIGIN/../../../../lib/eet:$ORIGIN/../../../../lib/ecore:$ORIGIN/../../../../lib/ecore_x:$ORIGIN/../../../../lib/ecore_input:$ORIGIN/../../../../lib/eeze:$ORIGIN/../../../../lib/ecore_file:$ORIGIN/../../../../lib/ecore_con:$ORIGIN/../../../../lib/eldbus'
 -Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/eina 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/evas 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/eo 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/ector 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/efl 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/emile 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/eet 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/ecore 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/ecore_x 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/ecore_input 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/eeze 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/ecore_file 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/ecore_con 
-Wl,-rpath-link,/<>/obj-x86_64-linux-gnu/src/lib/eldbus
/usr/bin/ld: 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_buffer.c.o:
 in function `evas_software_xlib_x_output_buffer_new':
./obj-x86_64-linux-gnu/../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:285:
 undefined reference to `XShmCreateImage'
/usr/bin/ld: 
./obj-x86_64-linux-gnu/../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:313:
 undefined reference to `XShmAttach'
/usr/bin/ld: 
./obj-x86_64-linux-gnu/../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:313:
 undefined reference to `XShmAttach'
/usr/bin/ld: 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_buffer.c.o:
 in function `evas_software_xlib_x_can_do_shm':
./obj-x86_64-linux-gnu/../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:235:
 undefined reference to `XShmQueryExtension'
/usr/bin/ld: 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_buffer.c.o:
 in function `evas_software_xlib_x_output_buffer_unref':
./obj-x86_64-linux-gnu/../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:393:
 undefined reference to `XShmDetach'
/usr/bin/ld: 
./obj-x86_64-linux-gnu/../src/modules/evas/engines/software_x11/evas_xlib_buffer.c:393:
 undefined reference to `XShmDetach'
/usr/bin/ld: 
src/modules/evas/engines/software_x11/libsoftware_x11.so.p/evas_xlib_buffer.c.o:
 in function `evas_software_xlib_x_output_buffer_paste':

Re: [E-devel] Terminology 1.8.1

[Ross Vandegrift]

On Wed, Aug 12, 2020 at 01:28:35PM +0930, Simon Lees wrote:
> On 8/12/20 5:47 AM, Boris Faure wrote:
> > == Download ==
> > The tarball can be found at :
> >   - 
> > https://download.enlightenment.org/rel/apps/terminology/terminology-1.8.1.tar.xz
> 
> I can't find this one on the server
> 
> >   - https://downloads.terminolo.gy/terminology-1.8.1.tar.xz
> 
> But this one is there fine.

This one was some trouble for me - looks like https over ipv6 is broken.
Forcing ipv4 or http works.

Ross


signature.asc
Description: PGP signature
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment 0.24.1 and Debian packaging for E 0.23

[Ross Vandegrift]

On Sun, Jul 12, 2020 at 09:11:24AM -0700, Jose R R wrote:
> Had to backport for Debian Buster Enlightenment DEB packages except the
> Debian packaging for Sid is one version below current E 0.24.1.
> http://deb.debian.org/debian/pool/main/e/e17/e17_0.23.1-5.debian.tar.xz
> 
> Notably, in the older packaging there seems to be references to phantom(?)
> freqset
> enlightenment_backlight
> cpuclock_sysfs

Yes, there are changes between 0.23 and 0.24.  Current packaging is at
https://salsa.debian.org/pkg-e-team/e/ in the debian/experimental
branch.  This (and newer efl) were uploaded, but the builds are failing
due to #959828.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Time for efl-one

[Ross Vandegrift]

On Wed, May 27, 2020 at 11:34:57AM +0200, Marcel Hollerbach wrote:
> after quite a big amount of work we have successfully landed this morning a
> update to our build system which enables to build efl as a single big .so
> instead of multiple seperated .so's. The layout is that every single .so is
> merged into efl-one.so except:
> - eolian: no normal app would benefit from it, and it would make our build
> *a lot* more complex
> - ecore_avahi: there is no real user for this within efl, in general i dont
> think anyone is going to benefit from it
> - efl_canvas_wl: This is also not beneficial to a standard efl application

Isn't this required by E with Wayland support?  If so, it might be worth
including - assuming there aren't other downsides.

> - elua: This is only for bindings.
> - ecore_drm / wayland : These are deprecated libs, not to confuse with
> ecore_wl2 / ecore_drm2, which is included in efl-one
> - exactness: Not useful for a normal efl app.
> 
> To build efl-one you need to pass: "-Defl-one=true" to meson. After this is
> done, additionally to all the smaller libs, efl-one.so will be build. The
> modules of ecore / evas etc. and all the binaries will link to efl-one.so
> not to the smaller libraries. However, for compatibility reasons, and
> complexity reasons, the small .so's are still build and installed.

If this works out, will this be the default at some point?  And I assume
that libefl-one will be the final name to avoid confusion with the
existing libefl?

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Wed, Apr 22, 2020 at 08:49:36PM +0100, Carsten Haitzler wrote:
> i pushed my segv fixed. can you try now? i tried and it comes up - just no
> backlight controls at all because it can't match a screen to the backlight
> device.

Same behavior - I never saw a segv.  The new dialog was helpful, but it cuts
off the text with scaling 1.2.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Thu, Apr 09, 2020 at 11:46:00AM +0100, Carsten Haitzler wrote:
> I expect to spin an e 0.24 release immediately after efl 1.24 is out. i hope 
> to
> have it done in 1-2 weeks.
> 
> please test e in git master NOW and send patches for fixes or improvements
> now... run e with asan enabled etc. :)

I found an odd interaction between the new backlight control and xrandr
screen setup.

My laptop's display in screen setup did not have the On box checked,
despite being the active (and only) screen at the time.  No idea how
that happened.  That prevented backlight control from working - I guess
it thought the screen was off.

If E has a display on, it seems like it should change that option if
backlight control now depends on it.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Wed, Apr 15, 2020 at 08:13:01AM +0100, Carsten Haitzler wrote:
> i want to kill the text console. i just don't see the point. it's so limited.
> it's no longer even ext mode. it's graphics mode with the kernel emulating 
> text
> on it for you.

For day-to-day, I agree.  But it's nice when I've junked up my WM or its
libraries and need an easy way to reinstall good packages... :)

> a graphical session with a fullscreen terminology gives the same
> effect/result just with a lot of added bonuses. hell terminology runs in a vt
> (but won't control backlight due to that needing infra that needs root 
> access).

Is there a way to force terminology to open a specific /dev/tty?  I just
tried to replace agetty in getty@.service with terminology.  It almost
works.  But it doesn't pick up the active terminal.  The process runs,
but nothing is drawn.

(I'm not saying this a good idea, terminology is scary to run as root.
But still, would be a fun trick.)

> at some point the kernel probably needs to wire up backlight to kms. also ddc
> controls probably need to be wired up with that too. you know e can control
> monitor backlights just like it controls your laptop internal screen 
> backlight?
> you can adjust brightness of each external monitor individually and e will
> also... fade these in and out to/from min to max etc. alongside your laptop
> internal backlight... :) it's lout of the box if you have libddcutil 
> installed.

I saw you mention this, but haven't had a chance to try it.  Been
testing without docking.  Definitely a cool feature though.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Tue, Apr 14, 2020 at 01:52:32PM +0100, Carsten Haitzler wrote:
> On Tue, 14 Apr 2020 15:00:28 +0930 Simon Lees  said:
> > https://fontesk.com/license/ofl-gpl/ and
> > https://fontlibrary.org/en/search?license=OFL%20(SIL%20Open%20Font%20License)=
> 
> Well at least that was helpful ... i've replaced them with SIL licensed fonts
> and made it explicit in COPYING as to their status and source. not sure it can
> be much clearer.

Sorry, didn't mean to be unhelpful.

The licenses on the new fonts are much clearer, thanks!

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Tue, Apr 14, 2020 at 12:43:59PM +0100, Carsten Haitzler wrote:
> On Mon, 13 Apr 2020 22:30:04 -0700 Ross Vandegrift  said:
> > sddm, and lxdm all returned to a black screen with no backlight control.  
> > Same
> > with startx and exiting to a text console.
> 
> Then turn the checkbox off. The point of fading to/from off is to have a
> glitch-free experience. All my boxes actually now do. They are black while
> booting, fade into an e splash screen, I jus stay in E until I'm done then
> power off the machine which  is a fade to black and then off. No console
> messages scrolling by or blinking cursors ... slick and clean.
> 
> If i want to have a mixed up environment and have that text console after or
> whatever - there is a checkbox there to swizzle. Reality is that the whole
> console ecosystem needs to move forward. For now gdm is doing it right. KDE,
> GNOME, E are doing it right by controlling backlight during a login session.
> The ecosystem moves forward when it's pushed. This is a push.

Yea, this makes sense to me.  It may be a surprising user experience to many
folks - for whatever reason, E seems to attract people who still want to run
startx manually.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Mon, Apr 13, 2020 at 02:49:11PM +0100, Carsten Haitzler wrote:
> On Sun, 12 Apr 2020 23:19:53 -0700 Ross Vandegrift  said:
> > - When I logout, E fades the backlight all the way to off, and nothing will
> >   turn it back on.  I have to reboot.  Logout works normally if I disable
> >   backlight fade in the compositor settings.
> 
> that's intended. by default it is expected that whatever takes over the screen
> after e sets backlight to whatever it should be set to. it's a problem with
> whatever runs after e not supporting backlight control.

I see - what display manager do you use that behaves correctly?

I tested a few, none of them restored the backlight after logout.  Only gdm3
had working backlight control, so at least I could turn it back on.  lightdm,
sddm, and lxdm all returned to a black screen with no backlight control.  Same
with startx and exiting to a text console.

> > - In the new shot module, right-clicking on text displays an illegibly tiny
> >   context menu.  I *think* it has cut/copy/paste options.  Other menus look
> >   normal.
> 
> zoom in. there are zoom controls right there...

Whoa, I've never seen zoom control that also affect the size of the menus.
That's kinda weird, but it works.


On Mon, Apr 13, 2020 at 02:59:37PM +0100, Carsten Haitzler wrote:
> On Sun, 12 Apr 2020 23:19:53 -0700 Ross Vandegrift  said:
> > - Are the fonts for the shot module redistributable?  BD_Cartoon_Shout.ttf
> >   and Suplexmentary_Comic_NC.ttf claim All rights reserved.  The homepage 
> > info
> >   for ComiquitaSans.ttf is wrong or defunct.  (see strings *.ttf | grep -Ei
> >   'reserved|copyright')  I couldn't find any info about 
> > FuturaHandwritten.ttf.
> 
> found them! :) in my history
> 
> https://fontmeme.com/fonts/comiquita-sans-font/
>  free for commercial use (that would allow redistribution etc.)
> https://fontmeme.com/fonts/bd-cartoon-shout-font/
>  also free for commercial use - use any way you like
> https://fontmeme.com/fonts/futura-handwritten-font/
>  also free for commercial use
> https://fontmeme.com/fonts/futura-handwritten-font/
>  same again
> 
> i'm going off the advertised "free for commercial use" which would say to me 
> we
> can redistribute it - it's not limiting usage to just personal use which is 
> the
> common "free but we can't redistribute that" box.

Thanks for the digging out the links.  I'm still a little unsure.  I see why
you say that, and I bet you're right.  But I think distro folks may look at the
text and decide it's not clearly permitting non-commercial use: it doesn't say
anything either way.

I'm not confidant the site has the right info.  For instance, they redistribute
many of the TeX Gyre fonts as "free for commercial use".  But that's not
correct, they have a real license and it prohibits redistribution of derived
works without a name change.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] e 0.24 release coming right after efl 1.24

[Ross Vandegrift]

On Thu, Apr 09, 2020 at 11:46:00AM +0100, Carsten Haitzler wrote:
> I expect to spin an e 0.24 release immediately after efl 1.24 is out. i hope 
> to
> have it done in 1-2 weeks.
> 
> please test e in git master NOW and send patches for fixes or improvements
> now... run e with asan enabled etc. :)

A few issues:

- When I logout, E fades the backlight all the way to off, and nothing will
  turn it back on.  I have to reboot.  Logout works normally if I disable
  backlight fade in the compositor settings.

- In the new shot module, right-clicking on text displays an illegibly tiny
  context menu.  I *think* it has cut/copy/paste options.  Other menus look
  normal.

- Are the fonts for the shot module redistributable?  BD_Cartoon_Shout.ttf
  and Suplexmentary_Comic_NC.ttf claim All rights reserved.  The homepage info
  for ComiquitaSans.ttf is wrong or defunct.  (see strings *.ttf | grep -Ei
  'reserved|copyright')  I couldn't find any info about FuturaHandwritten.ttf.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1

[Ross Vandegrift]

On Tue, Feb 18, 2020 at 12:02:45AM +, Carsten Haitzler wrote:
> On Mon, 17 Feb 2020 15:30:04 -0800 Ross Vandegrift  said:
> 
> > On Mon, Feb 17, 2020 at 09:41:48AM +, Carsten Haitzler wrote:
> > > On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift  
> > > said:
> > > > On Sat, Feb 15, 2020 at 09:37:59PM -0800, Jose R R wrote:
> > > > > For EFL, I replaced libcurl4-gnutls-dev with libcurl4-openssl-dev to
> > > > > be consistent with most of what I build --including reiser4 VMs for
> > > > > Google cloud env..
> > > > > The build finished but the logs showed *many* dh-missing files the
> > > > > Debian packaging had no *.installation instructions for.
> > > > 
> > > > These are left out intentionally so dh_missing is set to just warn.
> > > > Unfortunately, d/not-installed does not support wildcards yet - so
> > > > there's no (easy) way to suppress those messages.
> > > > 
> > > > > For E23.1 the build failed due to the copious quantity of dh-missing
> > > > > files.
> > > > 
> > > > Unlike efl, enlightenemnt's packaging is set to fail on any missing 
> > > > files.
> > > > (compare their d/rules and read the manpage for dh_missing).  There 
> > > > aren't
> > > > failures due to missing files on my local builds or the official 
> > > > buildds.
> > > > 
> > > > I don't know why your build failed.  But the patch is not correct.
> > > > usr/share/enlightenment/data is already in the install file, so it adds
> > > > nothing new.
> > > 
> > > actually a lot of those files being left out would be a bug. the missing
> > > checkme files for one are a going to break part of efl's behaviour
> > > (relocation).
> > 
> > This is sort of on purpose - given Debian's requirements, it seems
> > unlikely for those to work relocated.  I thought it'd be better for
> > those folks to build themselves.  But maybe I'm wrong - afaik, no one
> > has tried or asked for this feature so it's just a gut feeling.
> 
> if you included them someone can just tar up just the efl files from /usr and
> drop them (all relative paths the same) in /opt/pants and efl will work. or it
> should. it saves them having to compile again for a new prefix and can just 
> use
> the packaged files as-is... this actually allows some packaging systems like
> rpm's relocatable packages "just work" with efl. :) just saying that you force
> people into recompiling by making an effort to remove files... :)

Fair enough - I think the effort to support that is probably low.  But I'm
curious- why would someone want to do that?

> > > i'd also suggest the same simplification of the efl pkgs like e - merge
> > > them all into a single libefl
> > 
> > This wouldn't meet Debian's policy for packaging shared libraries - so
> > the result couldn't be included in Debian.  That's my goal, so I'm stuck
> > with the complication.
> 
> you can't merge? or you cant include binaries?

Strictly speaking, Debian policy requires both:

- Shared objects should be shipped in individual packges to minimize disruption
  due to incompatible versions.  e.g., if libfoo1 contains libfoo.so.1 AND
  libbar.so.1, and libbar bumps soname due to an abi/api break, then packages
  that depend on libfoo1 for libbar1  will break.  Splitting them up allows
  libbar.so.1 to remain installed for old programs.  This isn't such a concern
  for EFL's components, since they are required to be the same version anyhow.

  BUT - looking back at policy, it's not worded as a strict requirement.  I
  checked some shared lib packages on my laptop.  A few that bundle libs appear
  to have no reason beyond convenience.  So maybe I'll poke/ask around more and
  revisit this.

- Binaries can't ship in shared lib packages to support installing multiple
  versions of the same library.  In Debian, shared lib packages and all files
  in them names must include the soname.  So I can install packages that depend
  on libfoo1 and libfoo2 simultaneously.  But if libfoo1 and libfoo2 install
  different /usr/bin/foo, then the packages must conflict and cannot be 
coinstalled.

  The EFL packages don't conform to this perfectly - the eina package has had
  some other stuff added to avoid needing even more packages for a small number
  of files.  But technically, I should be cleaning that up over time.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1

[Ross Vandegrift]

On Mon, Feb 17, 2020 at 09:41:48AM +, Carsten Haitzler wrote:
> On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift  said:
> > On Sat, Feb 15, 2020 at 09:37:59PM -0800, Jose R R wrote:
> > > For EFL, I replaced libcurl4-gnutls-dev with libcurl4-openssl-dev to
> > > be consistent with most of what I build --including reiser4 VMs for
> > > Google cloud env..
> > > The build finished but the logs showed *many* dh-missing files the
> > > Debian packaging had no *.installation instructions for.
> > 
> > These are left out intentionally so dh_missing is set to just warn.
> > Unfortunately, d/not-installed does not support wildcards yet - so there's 
> > no
> > (easy) way to suppress those messages.
> > 
> > > For E23.1 the build failed due to the copious quantity of dh-missing 
> > > files.
> > 
> > Unlike efl, enlightenemnt's packaging is set to fail on any missing files.
> > (compare their d/rules and read the manpage for dh_missing).  There aren't
> > failures due to missing files on my local builds or the official buildds.
> > 
> > I don't know why your build failed.  But the patch is not correct.
> > usr/share/enlightenment/data is already in the install file, so it adds
> > nothing new.
> 
> actually a lot of those files being left out would be a bug. the missing
> checkme files for one are a going to break part of efl's behaviour
> (relocation).

This is sort of on purpose - given Debian's requirements, it seems
unlikely for those to work relocated.  I thought it'd be better for
those folks to build themselves.  But maybe I'm wrong - afaik, no one
has tried or asked for this feature so it's just a gut feeling.

> the cmake files missing will break some things like ecrire from
> compiling as they just use the native cmake checks (reminds me -0 i should
> just port it to meson :)).

The only missing cmake files are for the cxx bindings - which we don't
currently build.  I doubt anyone is missing them without the libs :)

The rest of the cmake files are in libefl-all-dev.

> i noticed elementary_perf itself is missing too. so
> is elementary_test - entirely. no package seems to include it (makes our lives
> hard when we ask people to run it and it doesn't exist). i've looked at
> https://packages.debian.org/search?searchon=names=elementary and 
> can't
> find it listed in the files for anything there. but oddly lots of data files
> that are only needed by it in libelementary-data - so shipping lots of useless
> data there not used by anything because the thing that needs the data files
> isn't packaged anywhere i can find.

Yea, that's not a great situation.  I didn't realize that  these could
be useful to non EFL devs.  I'll add them for the next release.

> for enlightenment, i don't see the point of splitting it up as it stands into
> enlightenment and enlightenment-data. it just makes life more complicated. 

It's an implementation detail - enlightenment always depends on the same
version of enlightenment-data.  apt will ensure they are
installed/upgraded together.  Users shouldn't ever have to care.

The purpose is to save bandwidth & storage for mirror operators.  -data
packages are arch independent to avoid making multiple copies per arch.

> i'd also suggest the same simplification of the efl pkgs like e - merge them 
> all
> into a single libefl

This wouldn't meet Debian's policy for packaging shared libraries - so
the result couldn't be included in Debian.  That's my goal, so I'm stuck
with the complication.

> my point here is... if you do not package everything together as one unit and
> split it out, be very careful how you split and if you leave things out then
> it's quite likely you may have broken some functionality. if you split, then 
> it
> may also break things unless the user remembers to install extra packages they
> may not realize they need. in the end what happens is people turn up with odd
> problems upstream and we go "WTF?" since don't realize the packages may have
> broken that in subtle ways.

IMO these would be packaging bugs - users should be able to ignore the
multiple packages.  The intended user experiences are like this:

- for an end user: install an EFL app (enlightenment, terminology, etc)
  and apt automatically installs all of the required stuff.
  - some packages are merely recommended (eg. terminology recommends
libelementary-bin for elementary_config.)  By default, apt treats
these as dependencies.  Users that change that know to expect
different behavior.

- for a developer: install libefl-all-dev and apt will automatically
  install all libs, headers, and build dependencies.

It pretty much works.  There have been a few rough cases (had to make
all rendering engines mandatory - apt wasn'

Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1

[Ross Vandegrift]

Hi Jose,

On Sat, Feb 15, 2020 at 09:37:59PM -0800, Jose R R wrote:
> For EFL, I replaced libcurl4-gnutls-dev with libcurl4-openssl-dev to
> be consistent with most of what I build --including reiser4 VMs for
> Google cloud env..
> The build finished but the logs showed *many* dh-missing files the
> Debian packaging had no *.installation instructions for.

These are left out intentionally so dh_missing is set to just warn.
Unfortunately, d/not-installed does not support wildcards yet - so there's no
(easy) way to suppress those messages.

> For E23.1 the build failed due to the copious quantity of dh-missing files.

Unlike efl, enlightenemnt's packaging is set to fail on any missing files.
(compare their d/rules and read the manpage for dh_missing).  There aren't
failures due to missing files on my local builds or the official buildds.

I don't know why your build failed.  But the patch is not correct.
usr/share/enlightenment/data is already in the install file, so it adds nothing
new.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [apps/ephoto] master 01/01: Add Keywords & drop deprecated Encoding from desktop files

[Ross Vandegrift]

okra pushed a commit to branch master.

http://git.enlightenment.org/apps/ephoto.git/commit/?id=8a6b42e776963e4e7ec5102376fbd4b474e42efc

commit 8a6b42e776963e4e7ec5102376fbd4b474e42efc
Author: Ross Vandegrift 
Date:   Wed Oct 2 13:45:13 2019 -0500

Add Keywords & drop deprecated Encoding from desktop files

Summary:
For more info see:
https://specifications.freedesktop.org/desktop-entry-spec/latest/apc.html

https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
https://wiki.gnome.org/Initiatives/GnomeGoals/DesktopFileKeywords

Reviewers: stephenmhouston

Reviewed By: stephenmhouston

Tags: #ephoto

Differential Revision: https://phab.enlightenment.org/D6866
---
 data/desktop/ephoto.desktop| 2 +-
 data/desktop/slideshow.desktop | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/data/desktop/ephoto.desktop b/data/desktop/ephoto.desktop
index 2a1172c..06f7fe9 100644
--- a/data/desktop/ephoto.desktop
+++ b/data/desktop/ephoto.desktop
@@ -1,5 +1,4 @@
 [Desktop Entry]
-Encoding=UTF-8
 Type=Application
 Name=Ephoto
 Name[ca]=Ephoto
@@ -34,3 +33,4 @@ Exec=ephoto %f
 Terminal=false
 
MimeType=inode/directory;image/png;image/jpeg;image/pjpeg;image/x-xpixmap;image/tiff;image/svg+xml;image/svg+xml-compressed;image/gif;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/bmp;image/x-bmp;image/x-tga;image/vnd.wap.wbmp;image/webp;image/vnd.microsoft.icon;image/ico;image/x-ico;image/x-win-bitmap;image/vnd.adobe.photoshop;image/x-psd;application/pdf;application/x-pdf;image/pdf;application/postscript;image/x-xcf;image/x-compre
 [...]
 Categories=Graphics;Viewer;
+Keywords=Picture;Slideshow;Graphics;
diff --git a/data/desktop/slideshow.desktop b/data/desktop/slideshow.desktop
index fc9ef1f..f355600 100644
--- a/data/desktop/slideshow.desktop
+++ b/data/desktop/slideshow.desktop
@@ -1,5 +1,4 @@
 [Desktop Entry]
-Encoding=UTF-8
 Type=Application
 Name=Slideshow
 Icon=ephoto
@@ -7,3 +6,4 @@ Exec=ephoto
 X-Gadget-Version=1.5
 X-Gadget-Bugreport=https://www.enlightenment.org/contrib/report-bug
 X-Gadget-Orientations=None
+Keywords=Picture;Slideshow;Graphics;

-- 

Re: [E-devel] Enlightenment DR 0.23.1 Release

[Ross Vandegrift]

On Thu, Sep 26, 2019 at 05:51:13PM +0100, Carsten Haitzler wrote:
> This is a bugfix and stability release for Enlightenment 0.23.
> 
>   * Fixed mixer notifications when volume didn't actually change
>   * Fixed build with newest EFL which does not still implicitly include 
> libuuid
> CFLAGS in efl-wl CFLAGS
>   * Fixed move/resize triggered by key bindings to work again
>   * Fixed NULL access on move begin that crashed.
> 
> Please see https://www.enlightenment.org/news/e0.23.1_release for more.

git.enlightenment.org doesn't have a v0.23.1 tag - miss a push?

Thanks,
Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/03: Use EFL version for doc tarball, not meson version

[Ross Vandegrift]

bu5hm4n pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=af5f37bd465edaa7eb9b8479df6e08788366447c

commit af5f37bd465edaa7eb9b8479df6e08788366447c
Author: Ross Vandegrift 
Date:   Sun Sep 22 23:30:25 2019 +

Use EFL version for doc tarball, not meson version

Reviewed-by: Marcel Hollerbach 
Differential Revision: https://phab.enlightenment.org/D10070
---
 doc/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/meson.build b/doc/meson.build
index b6bce8bf52..11e80dfadc 100644
--- a/doc/meson.build
+++ b/doc/meson.build
@@ -182,8 +182,8 @@ doc_target += custom_target('doxygen',
 )
 
 compress_target = custom_target('package_doc_tar',
-  command: [tar, '-C', meson.build_root(), '-cf', 
'efl-'+meson.version()+'.tar', 'html', 'man'],
-  output: 'efl-'+meson.version()+'.tar',
+  command: [tar, '-C', meson.build_root(), '-cf', 
'efl-'+meson.project_version()+'.tar', 'html', 'man'],
+  output: 'efl-'+meson.project_version()+'.tar',
   depends: doc_target,
   build_by_default: false
 )

-- 

Re: [E-devel] EFL Autotools freeze proposal

[Ross Vandegrift]

On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote:
> I think everyone is missing the point. What you are saying is true but
> that is why then they say if you want newer stuff to use a PPA for it
> even though its not in the main repo's

Yes, anyone can make a PPA.  But you're talking to the maintainers of
distro packaging - we try to put packages into distros for real :)

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Autotools freeze proposal

[Ross Vandegrift]

On Thu, Apr 25, 2019 at 04:40:40PM +, Jonathan Aquilina wrote:
> Hi Ross thanks for the tips, I don't think it is that easy to get
> something in to backports unless it fixes a bug or security
> vulnerability hence the use of PPA's they allow for bleeding edge
> stuff.

I think you're mixing up backports & stable.  Stable releases only
accept security fixes & small changes.  Backports provides a path for
selectively providing newer versions of software to stable.  It's an
opt-in repo.  See: https://help.ubuntu.com/community/UbuntuBackports
(The same is true for Debian.)

It shouldn't be too hard to get new backports accepted - the hardest
piece is probably finding someone to do the testing.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Autotools freeze proposal

[Ross Vandegrift]

On Thu, Apr 25, 2019 at 07:45:41AM +, Jonathan Aquilina wrote:
> @Stefan Schmidt I did a bit of digging one would need to package and
> setup a PPA to be able to support any and all versions of meason in
> this case in terms of supported releases. If you like I can try and
> learn how to package and get something going in terms of a PPA for
> meason and hell maybe even a PPA for enlightenment.

Hi Jonathan, if you're interested, start here:
https://wiki.ubuntu.com/UbuntuBackports
meson 0.49 from disco cleanly builds in bionic, though I didn't do any
testing of the result. (the meson tests do pass during build)

The Debian packages for efl 1.21 & e22 are in disco as well.  efl could
probably be backported now, e might need newer meson in bionic-backports
first.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL Autotools freeze proposal

[Ross Vandegrift]

On Wed, Apr 24, 2019 at 10:17:03AM +0200, Stefan Schmidt wrote:
> If I look around at other long term distro releases I can see this:
> - Debian stable has a recent backport
> - Ubuntu 18.04 (LTS) does ship 0.45.1 and I can't find a backport -> problem
> - Fedora has 0.47.2 back to fedora 28 and Fedora EPAL 7
> - OpenSuse Leap 15.0 actually offers 0.46.0 while Leap 42.3 is still on
> 0.40.1
> 
> To mean that means I would like to know if you consider Leap 42.3 an
> important target for an upcoming EFL release (does it actually have all
> the other deps fr such a new release?). Also we need to find out if
> there are backports of meson >= 0.46 for Ubuntu 18.04 which I have not
> found.

There's no existing backport but one has been requested:
https://bugs.launchpad.net/bionic-backports/+bug/1815092

I did a quick test, meson 0.49 builds in 18.04 with no changes & no
additional backports.  So I think this can be overcome for Ubuntu 18.04,
though it may need someone to push it along.

Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology 1.4.0

[Ross Vandegrift]

On Tue, Apr 09, 2019 at 11:19:15AM +0200, Boris Faure wrote:
> On 19-04-07 10:33, Ross Vandegrift wrote:
> > I think the expected test results have captured something about the 
> > environment
> > in the docker image borisfaure/terminology-ci.  I'd guess this is due to 
> > using
> > musl libc in alpine instead of glibc, but I don't have proof.  Is this
> > difference expected?  It'd be nice to use the tests on a normal distro.
> > 
> > The hashes above are stable w/gcc 8.3 & glibc 2.28 on Debian sid, even 
> > across
> > different versions of EFL.
> > 
> > Thanks,
> > Ross
> 
> Those tests do work fine on both gentoo and archlinux (using glibc) and
> alpine with musl. I think the change in behaviour is a debianism.

Ah bummer, bad guess on my part - I'll keep digging.

Thanks,
Ross


signature.asc
Description: PGP signature
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology 1.4.0

[Ross Vandegrift]

On Sun, Mar 31, 2019 at 12:30:36PM +0200, Boris Faure wrote:
> I am thus proud to release Terminology 1.4.0 today!
> 
> Additions:
>   * Add Continuous Integration on every push to the git repository
>   * Add a test framework on escape code parsing and interpreting
>   * Add more than 120 test files

Thanks Boris this is awesome!  When I run the tests, I get two failures:
c2.sh... (got c1d8061531d89476be61e948007ca239, expected 
9f264ee84b6d89f1f9fa7b76abd442c0) ✘
shift_in_out.sh... (got c3bb903237d9ef40d39ec07f328d922a, expected 
3896bcc6887998bbc41b43840a6b2e33) ✘

I think the expected test results have captured something about the environment
in the docker image borisfaure/terminology-ci.  I'd guess this is due to using
musl libc in alpine instead of glibc, but I don't have proof.  Is this
difference expected?  It'd be nice to use the tests on a normal distro.

The hashes above are stable w/gcc 8.3 & glibc 2.28 on Debian sid, even across
different versions of EFL.

Thanks,
Ross


signature.asc
Description: PGP signature
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 1.22 work items list

[Ross Vandegrift]

On Mon, Mar 04, 2019 at 04:58:24PM +0100, Marcel Hollerbach wrote:
> > On 03.03.19 21:49, Ross Vandegrift wrote:
> >> The build fails on evas modules when linking with -Wl,-z,defs.  Example 
> >> failure
> >> below.  I tried adding evas to the dependencies, but couldn't get it 
> >> working.
> >>
> >> Disabled strict linking for now just to get through a build.  Some 
> >> questions
> >> about the result:
> 
> Strict linking is something we could not achive for now, due to the fact
> that our evas source code structure and the way meson works is a little
> bit of a pain to get in sync. This is also the reason why evas_loaders /
> savers are only build statically, for now. The rendering engines can be
> both, either static or shared. Same for emotion players.

I see.  Strict linking isn't really a requirement for us, just a nice to
have.  Sounds like we should drop -Wl,-z,defs when the meson switch
hapens.  We can always add it back if/when the situation improves.

> >> - evas loaders/savers modules aren't generated.  Maybe built static in 
> >> spite of
> >>   -Devas-modules=shared?
> >> - maybe the same issue with emotion players

And that means these are on purpose.

> >> - no static libs are generated.  Is that intentional.
> 
> Which static libs are you refering to ? Most static libs that we have
> are only used in 1 place, and are added via a dependency and source
> code, i don't really have a strong reason why I did it like this, if
> this is a issue, it can be changed quickly :)

With autotools, --enable-static would output static libs along with the
shared objects for all of EFL.  Debian packages often ship static libs
in the -dev packages, EFL included.  If static EFL libs should be
deprecated that's probably okay - I don't know that anyone is using the
static libs we ship.

> >> - shaders aren't regenerated w/EFL_SHD_REGEN.  Easy to workaround, but just
> >>   want to make sure that's expected.
> 
> Yes, this is kind of intentional, regernerading the shader code is just
> a shell script, if someone wants to execute it, feel free, but i don't
> think we need a target for that ? If we do, then same as before, it can
> be changed quickly :)

Agreed, no target is needed.  Just noticed that it's different from
autotools build.


So: I'd say the meson build looks pretty good.  Just a few small tweaks
for us when the switch happens.

Thanks for the help,
Ross


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 1.22 work items list

[Ross Vandegrift]

On Thu, Feb 28, 2019 at 05:45:29PM +0100, Stefan Schmidt wrote:
> For packagers I would like to remind that this release will use the
> autotools builds system as official base. Tarballs will be generated
> with. We will also provide meson generated tarballs where we would
> appreciate testing (Simotek already promised to do that on OpenSUSE,
> other are more than welcome). This is especially critically as we will
> remove the autotools build system completely from master after this
> release is out. It will only remain in the efl-1.22 stable branch at
> that point. Don't stay behind and make sure your use cases are covered
> with meson.

Thanks Stefan.  I tested 1.22.0-alpha1 from git with the Debian packaging.

The build fails on evas modules when linking with -Wl,-z,defs.  Example failure
below.  I tried adding evas to the dependencies, but couldn't get it working.

Disabled strict linking for now just to get through a build.  Some questions
about the result:
- evas loaders/savers modules aren't generated.  Maybe built static in spite of
  -Devas-modules=shared?
- maybe the same issue with emotion players
- no static libs are generated.  Is that intentional.
- shaders aren't regenerated w/EFL_SHD_REGEN.  Easy to workaround, but just
  want to make sure that's expected.

Ross



FAILED: src/modules/evas/engines/buffer/libbuffer.so
ccache cc  -o src/modules/evas/engines/buffer/libbuffer.so 
'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o' 
'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_outbuf.c.o' 
-Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libbuffer.so -g -O2 
-fdebug-prefix-map=/build/efl-1.22.0-alpha1=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -Wl,-z,relro -Wl,-z,now -Wl,-z,defs 
-Wl,--as-needed -lm -ldl src/lib/eina/libeina.so.1.22.0 
src/lib/eo/libeo.so.1.22.0 src/lib/ector/libector.so.1.22.0 
src/lib/efl/libefl.so.1.22.0 src/lib/emile/libemile.so.1.22.0 
src/lib/eet/libeet.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 
src/static_libs/buildsystem/libbuildsystem.a 
src/wayland_protocol/libwayland_protocol.a -ldl 
/lib/x86_64-linux-gnu/libsystemd.so 
/usr/lib/x86_64-linux-gnu/libunwind-generic.so 
/usr/lib/x86_64-linux-gnu/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl 
-ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl 
/usr/lib/x86_64-linux-gnu/libfreetype.so 
/usr/lib/x86_64-linux-gnu/libfontconfig.so 
/usr/lib/x86_64-linux-gnu/libfribidi.so 
/usr/lib/x86_64-linux-gnu/libluajit-5.1.so 
/usr/lib/x86_64-linux-gnu/libharfbuzz.so 
/usr/lib/x86_64-linux-gnu/libwayland-client.so -lm -ldl -ldl -Wl,--end-group 
-pthread 
'-Wl,-rpath,$ORIGIN/../../../../lib/eina:$ORIGIN/../../../../lib/eo:$ORIGIN/../../../../lib/ector:$ORIGIN/../../../../lib/ector/software:$ORIGIN/../../../../lib/efl:$ORIGIN/../../../../static_libs/triangulator:$ORIGIN/../../../../static_libs/freetype:$ORIGIN/../../../../static_libs/draw:$ORIGIN/../../../../lib/emile:$ORIGIN/../../../../lib/eet:$ORIGIN/../../../../lib/ecore:$ORIGIN/../../../../static_libs/buildsystem:$ORIGIN/../../../../wayland_protocol'
 
-Wl,-rpath-link,/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eina:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eo:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ector:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ector/software:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/efl:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/triangulator:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/freetype:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/draw:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/emile:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eet:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ecore:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/buildsystem:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/wayland_protocol
/usr/bin/ld: 
src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o: in 
function `module_open':
./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/evas_engine.c:137: 
undefined reference to `_evas_module_engine_inherit'
/usr/bin/ld: 
src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o: in 
function `evas_render_engine_software_generic_clean':
./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:155:
 undefined reference to `evas_common_tilebuf_free'
/usr/bin/ld: 
./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:158:
 undefined reference to `evas_common_tilebuf_free_render_rects'
/usr/bin/ld: 
./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:159:
 undefined reference to `evas_common_tilebuf_free_render_rects'
/usr/bin/ld: 

Re: [E-devel] Terminology 1.3.1

[Ross Vandegrift]

On Sun, Dec 16, 2018 at 02:36:53PM +0100, Boris Faure wrote:
> The issue is a Remote Code Execution vulnerability caused by
>  Terminology's special escape codes.  Those can already be disabled in
>  the Settings panel.

Hi Ben - you mentioned getting a CVE in the phab report.  Has that been
assigned?

Ross


signature.asc
Description: PGP signature
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology 1.3.0

[Ross Vandegrift]

On Fri, Nov 23, 2018 at 09:09:50PM +0100, Boris Faure wrote:
> On this Black Friday, I am pleased to release Terminology 1.3.0!

Thanks Boris - is git up to date?  I don't see any changes related 1.3.0 or a
tag for the release.

Ross


signature.asc
Description: PGP signature
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Example files missing from EFL tarballs

[Ross Vandegrift]

On Tue, Aug 21, 2018 at 05:00:22PM +0200, Stefan Schmidt wrote:
> On 08/20/2018 12:09 PM, Stefan Schmidt wrote:
> > On 08/18/2018 07:27 PM, Ross Vandegrift wrote:
> >> The EFL tarballs are missing some files under src/examples.  Is this on
> >> purpose?  Makefile.in/gitignore differences seem normal, but source and
> >> resource files seem strange.
> > 
> > This is indeed strange to see. I will investigate once I have the make
> > doc issue sorted.
> 
> I started to look into this today and I have to say you found a gift
> that keeps giving. :/
> 
> Already 7 patches in my branch but still missing at least elementary and
> ecore to go through. Good find. Once all teh patches are through review
> and landed I will make sure they get backported into the stable branch.

Oh no, sorry about that!

Thanks for all the help Stefan,

Ross

--
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] EFL 1.21 ecore_wl2 dmabuf module & strict linking

[Ross Vandegrift]

Hi all,

I started working through the 1.21 update for the Debian packages.  We use
"-Wl,-z defs" for strict linking, and it's causing an issue with the ecore_wl2
dmabuf module.

If I manually run libtool, adding "lib/ecore_wl2/libecore_wl2.la
lib/eina/libeina.la" to the command line, it works.  But I don't know enough
about libtool to fix the automake file.

Here's the failure:
/bin/bash ../libtool  --tag=CC --tag=disable-static  --mode=link gcc  -g -O2 
-fdebug-prefix-map=/build/efl-1.21.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -fpie -module -no-undefined 
-avoid-version -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -lm -ldl 
-fPIC -DPIC -pie -rdynamic -o modules/ecore_wl2/engines/dmabuf/module.la -rpath 
/usr/lib/x86_64-linux-gnu/ecore_wl2/engines/dmabuf/v-1.21 
lib/ecore_wl2/modules_ecore_wl2_engines_dmabuf_module_la-ecore_wl2_surface_module_dmabuf.lo
  -lrt
libtool: link: gcc -shared  -fPIC -DPIC  
lib/ecore_wl2/.libs/modules_ecore_wl2_engines_dmabuf_module_la-ecore_wl2_surface_module_dmabuf.o
   -lm -ldl -lrt  -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -Wl,-z -Wl,defs -Wl,--as-needed   -Wl,-soname -Wl,module.so -o 
modules/ecore_wl2/engines/dmabuf/.libs/module.so
/usr/bin/ld: 
lib/ecore_wl2/.libs/modules_ecore_wl2_engines_dmabuf_module_la-ecore_wl2_surface_module_dmabuf.o:
 in function `ecore_wl2_surface_module_dmabuf_init':
./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:253: undefined reference 
to `ecore_wl2_surface_manager_add'
/usr/bin/ld: 
lib/ecore_wl2/.libs/modules_ecore_wl2_engines_dmabuf_module_la-ecore_wl2_surface_module_dmabuf.o:
 in function `_evas_dmabuf_surface_flush':
./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:233: undefined reference 
to `ecore_wl2_buffer_destroy'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:227: 
undefined reference to `eina_list_remove_list'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:229: 
undefined reference to `ecore_wl2_buffer_busy_get'
/usr/bin/ld: 
lib/ecore_wl2/.libs/modules_ecore_wl2_engines_dmabuf_module_la-ecore_wl2_surface_module_dmabuf.o:
 in function `_evas_dmabuf_surface_post':
./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:190: undefined reference 
to `ecore_wl2_buffer_unlock'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:193: 
undefined reference to `ecore_wl2_buffer_busy_set'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:194: 
undefined reference to `ecore_wl2_buffer_age_set'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:196: 
undefined reference to `ecore_wl2_surface_window_get'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:198: 
undefined reference to `ecore_wl2_buffer_wl_buffer_get'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:199: 
undefined reference to `ecore_wl2_window_buffer_attach'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:200: 
undefined reference to `ecore_wl2_window_damage'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:202: 
undefined reference to `ecore_wl2_window_commit'
/usr/bin/ld: 
lib/ecore_wl2/.libs/modules_ecore_wl2_engines_dmabuf_module_la-ecore_wl2_surface_module_dmabuf.o:
 in function `_evas_dmabuf_surface_wait':
./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:110: undefined reference 
to `ecore_wl2_buffer_busy_get'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:110: 
undefined reference to `ecore_wl2_buffer_busy_get'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:115: 
undefined reference to `ecore_wl2_buffer_age_get'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:135: 
undefined reference to `eina_list_remove'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:136: 
undefined reference to `ecore_wl2_buffer_destroy'
/usr/bin/ld: ./src/lib/ecore_wl2/ecore_wl2_surface_module_dmabuf.c:142: 
undefined reference to `ecore_wl2_surface_buffer_create'
lib/efreet/efreet_trash.c:129:43: warning: '/.Trash-' directive output may be 
truncated writing 8 bytes into a region of size between 1 and 4096 
[-Wformat-truncation=]
 snprintf(buf, sizeof(buf), "%s/.Trash-%u", path, (unsigned int) 
getuid());
   ^~~~
In file included from /usr/include/stdio.h:862,
 from ../src/lib/eina/eina_inline_array.x:24,
 from ../src/lib/eina/eina_array.h:495,
 from ../src/lib/eina/eina_file.h:28,
 from ../src/lib/eina/Eina.h:221,
 from ../src/lib/ecore_file/Ecore_File.h:9,
 from lib/efreet/efreet_trash.c:10:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note: 
'__builtin___snprintf_chk' output between 10 and 4114 bytes into a destination 
of size 4096
   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
  

[E-devel] Example files missing from EFL tarballs

[Ross Vandegrift]

Hello,

The EFL tarballs are missing some files under src/examples.  Is this on
purpose?  Makefile.in/gitignore differences seem normal, but source and
resource files seem strange.

Diff of "cd src/examples; find" is below for 1.21.0-beta2, though I noticed
this by looking at 1.20.7.

Thanks,
Ross

--- efl-1.21.0-beta2-gittag 2018-08-18 10:23:15.880572641 -0700
+++ efl-1.21.0-beta2-tarball2018-08-18 10:23:28.000926370 -0700
@@ -4,7 +4,6 @@
 ./eolian_cxx.mk
 ./ecore_avahi
 ./ecore_avahi/ecore_avahi_example.c
-./ecore_avahi/.gitignore
 ./ecore_avahi/ecore_avahi_browse_example.c
 ./evas
 ./evas/evas-3d-md2.c
@@ -93,29 +92,19 @@
 ./evas/resources/models/NoNormal_UVs_Colors.ply
 ./evas/resources/models/convex_hull
 ./evas/resources/models/convex_hull/plain_blender_ch.ply
-./evas/resources/models/convex_hull/sonic_blender_ch.ply
-./evas/resources/models/convex_hull/home_blender_ch_test.ply
 ./evas/resources/models/convex_hull/torus_blender_ch.ply
 ./evas/resources/models/convex_hull/cube_blender_ch.ply
-./evas/resources/models/convex_hull/cube_blender_ch_test.ply
 ./evas/resources/models/convex_hull/sphere_blender_ch.ply
 ./evas/resources/models/convex_hull/column_blender_ch.ply
-./evas/resources/models/convex_hull/column_blender_ch_test.ply
 ./evas/resources/models/convex_hull/column.ply
 ./evas/resources/models/convex_hull/plain.ply
 ./evas/resources/models/convex_hull/eagle_blender_ch.ply
-./evas/resources/models/convex_hull/eagle_blender_ch_test.ply
-./evas/resources/models/convex_hull/plain_blender_ch_test.ply
-./evas/resources/models/convex_hull/torus_blender_ch_test.ply
-./evas/resources/models/convex_hull/sonic_blender_ch_test.ply
-./evas/resources/models/convex_hull/sphere_blender_ch_test.ply
 ./evas/resources/models/convex_hull/home_blender_ch.obj
 ./evas/resources/models/Normal_NoUVs_NoColors.ply
 ./evas/resources/images
 ./evas/resources/images/im1.png
 ./evas/resources/images/cube1.png
 ./evas/resources/images/wood.jpg
-./evas/resources/images/star.jpg
 ./evas/resources/images/enlightenment.png
 ./evas/resources/images/sweet_home_reversed.png
 ./evas/resources/images/rocks.jpg
@@ -135,9 +124,7 @@
 ./evas/evas-events.c
 ./evas/evas-stacking.c
 ./evas/evas-3d-obj.c
-./evas/README
 ./evas/evas-vg-simple.c
-./evas/.gitignore
 ./evas/evas-multiseat-events.c
 ./evas/Makefile.examples
 ./evas/evas-images4.c
@@ -173,7 +160,6 @@
 ./eio/efl_io_manager_open_multi.c
 ./eio/eio_sentry.c
 ./eio/eio_file_ls.c
-./eio/.gitignore
 ./eio/Makefile.examples
 ./edje
 ./edje/text.edc
@@ -224,7 +210,6 @@
 ./edje/wikimedia.svg
 ./edje/edje_example.edc
 ./edje/edje-drag.c
-./edje/edje-map-color.edc
 ./edje/edje-perspective.c
 ./edje/dst.svg
 ./edje/edje-animations.c
@@ -238,7 +223,6 @@
 ./edje/physics_complex.edc
 ./edje/external_elm_panes.edc
 ./edje/multiseat_custom_names.edc
-./edje/edje-anchors.c
 ./edje/edje-color-class.c
 ./edje/yadis.svg
 ./edje/signals-messages.edc
@@ -246,7 +230,6 @@
 ./edje/venus.svg
 ./edje/favorite_off.svg
 ./edje/ibm.svg
-./edje/.gitignore
 ./edje/edje-multiseat.c
 ./edje/Makefile.examples
 ./edje/physics_basic.edc
@@ -275,7 +258,6 @@
 ./edje/embryo_timer.edc
 ./edje/radialgrad1.svg
 ./edje/edje-swallow2.c
-./edje/edje-anchors.edc
 ./edje/hg0.svg
 ./edje/animations2.c
 ./edje/external_elm_check.edc
@@ -310,11 +292,9 @@
 ./eldbus/ofono-dial.c
 ./eldbus/server.c
 ./eldbus/simple-signal-emit.c
-./eldbus/.gitignore
 ./eldbus/Makefile.examples
 ./eina
 ./eina/eina_strbuf_01.c
-./eina/eina_strbuf_02.c
 ./eina/eina_str_01.c
 ./eina/eina_hash_02.c
 ./eina/eina_error_01.c
@@ -323,7 +303,6 @@
 ./eina/eina_tiler_01.c
 ./eina/eina_inarray_03.c
 ./eina/eina_value_03.c
-./eina/eina_value_04.c
 ./eina/eina_list_04.c
 ./eina/eina_file_02.c
 ./eina/eina_inarray_02.c
@@ -341,16 +320,13 @@
 ./eina/chat.xml
 ./eina/eina_value_01.c
 ./eina/eina_value_02.c
-./eina/.gitignore
 ./eina/Makefile.examples
 ./eina/EinaHash01.cs
-./eina/eina_tiler_02.c
 ./eina/eina_tmpstr_01.c
 ./eina/eina_iterator_01.c
 ./eina/EinaBinbuf01.cs
 ./eina/eina_list_01.c
 ./eina/eina_list_02.c
-./eina/eina_simple_xml_parser_02.c
 ./eina/eina_inarray_01.c
 ./eina/eina_inlist_03.c
 ./eina/eina_hash_03.c
@@ -365,12 +341,10 @@
 ./eina/eina_hash_08.c
 ./eina/eina_array_02.c
 ./eina/eina_hash_05.c
-./eina/exia.xml
 ./emotion
 ./emotion/emotion_generic_example.c
 ./emotion/emotion_signals_example.c
 ./emotion/emotion_basic_example.c
-./emotion/.gitignore
 ./emotion/Makefile.examples
 ./emotion/emotion_border_example.c
 ./emotion/emotion_generic_subtitle_example.c
@@ -379,21 +353,16 @@
 ./emotion.mk
 ./ethumb_client.mk
 ./eolian_cxx
-./eolian_cxx/colourable_stub.c
 ./eolian_cxx/eolian_cxx_callbacks_01.cc
 ./eolian_cxx/ns_colourablesquare.eo
-./eolian_cxx/colourablesquare_stub.c
 ./eolian_cxx/colourable_cxx.cc
 ./eolian_cxx/colourable_stub.h
 ./eolian_cxx/ns_colourable.eo
 ./eolian_cxx/colourable.c
-./eolian_cxx/eolian_cxx_simple_01_cxx_impl.cc
 ./eolian_cxx/eolian_cxx_simple_01.cc
-./eolian_cxx/.gitignore
 ./eolian_cxx/Makefile.examples
 

Re: [E-devel] edje_cc efreetd sandbox access violation issues

[Ross Vandegrift]

On Fri, Apr 06, 2018 at 11:28:58AM -0400, William L. Thomson Jr. wrote:
> On Fri, 6 Apr 2018 14:10:51 +0900 Carsten Haitzler (The Rasterman) 
>  wrote:
> > limiting your sandbox from
> > accessing XDG_RUNTIME_DIR is probably a very bad idea, because this
> > is the standard "xdg" location for any run-time files. sockets or any
> > other relevant "only around during runtime of a users log in session"
> > files (thus they are not expected to persist and this dir and it not
> > shared between users etc.) :)

Well, it's not quite that simple during package builds.  Debian has a
similar policy because users may build packages outside of a chroot.
If the build process writes outside of the build dir, this could mess
with their real home dirs.

I imagine the Gentoo motivation is the same.

> This is during build, nothing is running. Also this violates Gentoo
> distro specific build policies.
> 
> "All packages must build correctly when sandbox is active. "
> https://devmanual.gentoo.org/general-concepts/sandbox/

Solution is to run WITH XDG_RUNTIME_DIR and HOME set to a temp dir:
https://sources.debian.org/src/efl/1.20.7-4/debian/fake_home.sh/

Example use:
https://sources.debian.org/src/efl/1.20.7-4/debian/rules/#L62

> Seems like something does need to be fixed.

Yes - the build environment!

Ross


signature.asc
Description: PGP signature
--
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] EFL packaging on Debian

[Ross Vandegrift]

On Mon, Mar 19, 2018 at 11:21:51AM +0900, Stefan Schmidt wrote:
> I just did run through my monthly packaging status update and was
> pleased to see that efl 1.20.7 has entered Debian unstable a few days
> back.
> 
> I wanted to take this opportunity to thank Ross for his constant work
> on getting this worked out! :-)

Thanks!  Binary packages aren't actually available yet, we're working
around some breakage in dependencies.  Shouldn't be too long.

Ross

--
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] Autotools removal

[Ross Vandegrift]

On Mon, Nov 06, 2017 at 12:13:58PM +0100, jeanseb.vale...@free.fr wrote:
> Debian is stucked to e17 ! 
> 
> 
> Should be wise to ask for those who want to compile recent version using more 
> recent meson than debian one. 

E21 is available in Debian experimental, and E22 will be ready soon.

Ross

--
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] Autotools removal

[Ross Vandegrift]

On Mon, Nov 06, 2017 at 01:26:02PM +, Mike Blumenkrantz wrote:
> I'd rather not start creating meta build systems that we then need to track
> and maintain. I will temporarily add a tarball for meson 0.39 until Debian
> decides to do an update for the package.

I wouldn't bother - there's already a backport of meson 0.42 available
for current Debian stable.  It'd be reasonable to require that the user
installs that version first.

Debian unstable has meson 0.43, so all is good there.

Ross

--
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] EFL 1.20.3 release

[Ross Vandegrift]

On Thu, Oct 19, 2017 at 05:26:43PM -0400, Cedric Bail wrote:
> Our fifth update on the 1.20 release.

git fetch didn't find a tag for 1.20.5.  Could one be pushed?

Thanks,
Ross

--
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] Evas_Engine_Software_X11.h missing on purpose?

[Ross Vandegrift]

On Mon, Oct 16, 2017 at 01:34:10PM +0900, Carsten Haitzler wrote:
> On Mon, 16 Oct 2017 13:10:54 +0900 Jean-Philippe André  
> said:
> > Those engine-specific headers exposed structures containing data that
> > should have been kept internal, and bind the applications to a specific
> > display system, which we've been trying to abstract.
> > 
> > Now I have to admit that I hadn't heard of exactimage before and thus
> > wonder why this header is required?
> 
> well indeed they do use evas. i think we need to keep installing our engine
> headers because basically this is what efl did prior to the "big merge". the
> engine headers can be used to hand-init your own engine and this is what
> ecore-evas did and relied on as it was distributed separately to evas...

Thanks for the info - want me to add to phab?

Ross

--
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] Evas_Engine_Software_X11.h missing on purpose?

[Ross Vandegrift]

Hi all,

I'm testing Debian packages that use EFL against 1.20.4, and exactimages
fails to build because Evas_Engine_Software_X11.h is no longer installed
by make install. [1]

Probably this is a change from a long time ago - but I'm having trouble
confirming.  Was this intentional?

Thanks,
Ross

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878572

--
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] meson vs autotools in enlightenment

[Ross Vandegrift]

On Wed, Sep 06, 2017 at 09:38:11AM +0930, Simon Lees wrote:
> Currently we require a meson version thats newer then what is shipped on
> debian, so we know it will fail to build at the first check. I plan to
> setup a debian VM to check whether lowering this version is enough to
> get it building but if you want to go forward from here we should be
> targeting Meson 0.30.0 not 0.40.0.

I just gave this a try.  meson 0.37 from stretch fails, but it doesn't
look like an E problem to me.  meson gets permission denied trying to
mkdir /usr/share/meson/mesonbuild/__pycache__ without root.  Sounds like
a meson issue, but I've never used meson before tonight.

meson 0.42 in sid works great.

Ross



(stretch-efl)ross@stgulik:~/src/e/e$ meson . build
The Meson build system
Version: 0.37.1
Source dir: /home/ross/src/e/e
Build dir: /home/ross/src/e/e/build
Build type: native build
Project name: enlightenment
Native c compiler: ccache cc (gcc 6.3.0)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Traceback (most recent call last):
  File "/usr/share/meson/mesonbuild/mesonmain.py", line 292, in run
app.generate()
  File "/usr/share/meson/mesonbuild/mesonmain.py", line 177, in generate
intr.run()
  File "/usr/share/meson/mesonbuild/interpreter.py", line 2223, in run
super().run()
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 124, in run
self.evaluate_codeblock(self.ast, start=1)
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 145, in 
evaluate_codeblock
raise e
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 139, in 
evaluate_codeblock
self.evaluate_statement(cur)
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 152, in 
evaluate_statement
return self.assignment(cur)
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 547, in assignment
value = self.evaluate_statement(node.value)
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 150, in 
evaluate_statement
return self.function_call(cur)
  File "/usr/share/meson/mesonbuild/interpreterbase.py", line 371, in 
function_call
return self.funcs[func_name](node, self.flatten(posargs), kwargs)
  File "/usr/share/meson/mesonbuild/interpreter.py", line 1382, in 
func_run_command
self.subdir, in_builddir)
  File "/usr/share/meson/mesonbuild/interpreter.py", line 74, in __init__
pc, self.stdout, self.stderr = self.run_command(command_array, source_dir, 
build_dir, subdir, in_builddir)
  File "/usr/share/meson/mesonbuild/interpreter.py", line 94, in run_command
return Popen_safe(command_array, env=child_env, cwd=cwd)
  File "/usr/share/meson/mesonbuild/mesonlib.py", line 396, in Popen_safe
stderr=stderr, **kwargs)
  File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1289, in _execute_child
raise child_exception_type(errno_num, err_msg)
PermissionError: [Errno 13] Permission denied

--
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] EFL 1.19.0-beta3 (from git) package for Debian Experimental

[Ross Vandegrift]

On Thu, Mar 23, 2017 at 07:04:14PM +0900, Carsten Haitzler wrote:
> On Thu, 23 Mar 2017 00:21:38 -0700 Jose R R  said:
> >
> you dont have to disable tests... you actually HAVE to enable them with
> --with-tests=regular or --with-tests=coverage ... AND you then also have to do
> "make check" to compile AND run them... it requires effort to enable them and
> run them.

He's attempting to use the packaging from Debian experimental, which
enables & automatically runs make check.

> > override_dh_auto_configure:
> > dh_auto_configure --verbose -- \
> > --disable-rpath \
> > --disable-silent-rules \
> > --enable-doc \
> > --with-profile=dev \
> > --with-tests=regular \
> > --with-crypto=gnutls \
> > --disable-tslib \
> > --enable-liblz4 \
> > --enable-xinput22 \
> > --enable-image-loader-webp \
> > --enable-harfbuzz \
> > --enable-systemd \
> > --enable-static \
> > --enable-image-loader-webp \
> > --with-generic_vlc \
> > --enable-fb \
> > $(arch_flags)
> > 
> > That's how DEBs in reference snapshot were generated *finally*.
> 
> no wayland i see. :( also no ibus input method support either.

Last I heard, using wayland was only recommended if you followed git.
If that's no longer true, it could be enabled in the next release.

Ross

--
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] EFL 1.19.0-beta3 (from git) package for Debian Experimental

[Ross Vandegrift]

On Wed, Mar 22, 2017 at 04:50:38AM -0700, Jose R R wrote:
> First I modify debian/rules, option: --enable-fb
> -
> [...]
> ifeq (linux,$(DEB_HOST_ARCH_OS))
> arch_flags += --enable-fb<=## Directive is overlooked. DEB
> build fails *because* it's missing
> [...]
> override_dh_auto_configure:
> dh_auto_configure --verbose -- \
> [...]
> --enable-fb \   <=## Added explicitly here, satisfies dh_install
> $(arch_flags)
> [...]
> 

You only need this change because you're calling debian/rules directly.
If you use dpkg-buildpackage then DEB_HOST_ARCH_OS will be set, and the
Makefile will automatically add --enable-fb.

Ross

--
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] EFL 1.19.0-beta3 (from git) package for Debian Experimental

[Ross Vandegrift]

On Mon, Mar 20, 2017 at 04:44:53PM -0700, Jose R R wrote:
> On Mon, Mar 20, 2017 at 1:19 PM, Ross Vandegrift <r...@kallisti.us> wrote:
> >
> > On Sun, Mar 19, 2017 at 11:47:39PM -0700, Jose R R wrote:
> > > https://git.enlightenment.org/core/efl.git/
> > >
> > > Notwithstanding, I intended to package Enlightenment and make download
> > > available for my SourceForge Debian-Reiser4 netboot installer.
> > >
> > > EFL debian packaging:
> > > http://http.debian.net/debian/pool/main/e/efl/efl_1.18.4-1.debian.tar.xz
> >
> > Any reason you want to rebuild from git instead of using the packages in
> > experimental?  If you've found a problem, I'd like to fix it.  On sid &
> > stretch they should install without difficulty.
> 
> I will try anything, until something works. Then I will proceed to
> work on the backport for the stable Debian (Jessie) to complement
> Reiser4 kernel, backported{ linux-base, nfs-common, reiser4progs
> (reiser4 fs utilities), etc.}. If I install packages directly from
> Debian unstable(Sid), testing (Stretch), or -- in this particular
> case, experimental -- repositories onto stable/Jessie-backports, the
> end user will end up with dependency hell, i.e, broken installation.

Oh I see - I misunderstood your previous message and thought you were
targeting sid.  You need to backport + rebuild for jessie.  IIRC, the
only change I needed was to remove the auto dbgsym stuff.

[snip]
> FAIL: tests/evas/evas_suite
> ===
> 
> /mnt/caxtolli/usr/src/build/enlightenment-debian/sid-omeyi/efl-1.18.4/src/tests/evas/.libs/evas_suite:
>  symbol lookup error: 
> /mnt/caxtolli/usr/src/build/enlightenment-debian/sid-omeyi/efl-1.18.4/src/lib/efl/.libs/libefl.so.1:
>  undefined symbol: _eo_call_end
> FAIL tests/evas/evas_suite (exit status: 127)

This seems suspicious - the linker can't find a symbol in libefl.so.
Are you building with some other patches?

[snip]
> FAIL: tests/eio/eio_suite
> =
> 
> Running suite(s): Eio
[snip]
> 98%: Checks: 51, Failures: 1, Errors: 0
> tests/eio/eio_test_manager.c:68:F:Eio Job:efl_io_manager_test_ls_funcs:0: 
> Failure '(*number_of_listed_files) != test_count' occurred

I don't recall seeing this test fail before, sorry.

Ross

--
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] EFL 1.19.0-beta3 (from git) package for Debian Experimental

[Ross Vandegrift]

On Sun, Mar 19, 2017 at 11:47:39PM -0700, Jose R R wrote:
> https://git.enlightenment.org/core/efl.git/
> 
> Notwithstanding, I intended to package Enlightenment and make download
> available for my SourceForge Debian-Reiser4 netboot installer.
> 
> EFL debian packaging:
> http://http.debian.net/debian/pool/main/e/efl/efl_1.18.4-1.debian.tar.xz

Any reason you want to rebuild from git instead of using the packages in
experimental?  If you've found a problem, I'd like to fix it.  On sid &
stretch they should install without difficulty.

Are you using sbuild?  I've seen issues like the test failures below
under sbuild - some EFL tests get incorrect info about filesystem
permissions.  I use pbuilder, so I haven't tracked this down.

Ross

--
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] build system

[Ross Vandegrift]

On Tue, Jan 17, 2017 at 09:10:48AM +0100, Lionel Orry wrote:
> On Tue, Jan 17, 2017 at 1:22 AM, Simon Lees  wrote:
> > How many major distro's are shipping these out of the box? we don't
> > really want to add another hurdle to users building by needing to
> > manually install a build system first, we also don't want to add a
> > hurdle to distro packagers in needing to package a new build system just
> > to package efl (most distro's will require the build system to be
> > packaged).
> >
> > ​
> In the case of Waf, the author recommends to ship it directly with the
> source code. It's shipped as a single file of 80KB, no more.​
> 
> ​That way you always get the exact same build system version and you remove
> burden of portability between distros, and the only dependency you need is
> python.​

Simon's concern is particularly valid in the case of waf.  According to
the author, waf's design includes features to make packaging difficult.

Discussion:
http://groups.google.com/group/waf-users/browse_thread/thread/88ad357bf2bf59f4/7261615b56c07eea

Ross

--
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] Fwd: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7

[Ross Vandegrift]

On Wed, Nov 23, 2016 at 07:42:39AM +0900, Carsten Haitzler wrote:
> if you don't upgrade efl, i guarantee you have security exploit possibilities
> in various image loaders in efl. so if you care about security you won't do
> this "let's backport just to fix this cve" and actually upgrade. :)

That conditional is false, and anyway it's done.  I'm working on a new
release of EFL, but it'll be a while before it's in unstable:
https://sourceforge.net/p/enlightenment/mailman/enlightenment-devel/thread/2016133421.hibvy5veyvoklhmf%40vanvanmojo.kallisti.us/#msg35485476

Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Fwd: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7

[Ross Vandegrift]

On Tue, Nov 22, 2016 at 06:41:43PM +0100, Boris Faure wrote:
> EFL 1.8 is pretty old. I stopped caring about so old versions.

I figured - that's why I didn't report a bug.

> Do you have a plan to update EFL?

Yes, but it'll take some time before it's available in unstable.

Details:
https://sourceforge.net/p/enlightenment/mailman/enlightenment-devel/thread/2016133421.hibvy5veyvoklhmf%40vanvanmojo.kallisti.us/#msg35485476

Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Fwd: [oss-security] Re: CVE request: Escape Sequence Command Execution vulnerability in Terminology 0.7

[Ross Vandegrift]

On Wed, Nov 09, 2016 at 11:17:55PM +0100, Boris Faure wrote:
> > > https://git.enlightenment.org/apps/terminology.git/commit/?id=b80bedc7c21ecffe99d8d142930db696eebdd6a5
> > >> src/bin/termptyesc.c
> > 
> > Use CVE-2015-8971.
> 
>   For those who wonder, this issue has been fixed in Terminology 0.9.0
> (and 0.9.1).  I do hope this will speed up the process to update
> Terminology in Debian.

terminology 0.9.1 seems to have some regressions when used with EFL 1.8
(new tab segfaults, resizing occasionally freezes).  So for now, sid will
get 0.7.0-2 with just the backported fix that's already in
jessie-updates.

Ross


signature.asc
Description: PGP signature
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL packaging on Debian

[Ross Vandegrift]

On Thu, Nov 10, 2016 at 11:06:04AM +0100, Stefan Schmidt wrote:
> I did my monthly packaging update again and was hoping this moved to 
> unstable by now. It is still in experimental only as far as I can see. 
> Is there an automatic way this packages get from experimental to 
> unstable, testing stable? Or are you supposed to pursue Albin again to 
> get it uploaded to unstable?

A few items on the current status:

1) All uploads will go through Albin (or some other sponsor).

While reviewing, Albin had some questions on the internal EFL deps and
shared symbol versioning.  The packaging produces unusually strict (for
Debian) dependencies.  We're working through it.

2) experimental -> unstable is a manual migration.  Once in unstable,
packages automatically migrate to testing, and then to the next stable
release.  Packages are not normally added to existing stable releases.

We uploaded to experimental for additional testing opportunity, since
Debian contains packages which depend on EFL.  When we're happy with the
status, they'll be uploaded to unstable.

3) The packages in experimental break binary compatability with the
existing unstable packages.  For instance, you can't use the
experimental packages break the terminology packages in unstable.

(Why?  The packages in unstable preserve a bit of pre-1.0 eina ABI that
was released into Debian many years ago.  That requires disabling magic
debug, and in EFL 1.17 tests break with this config.  We decided the
eina tests are more valuable than the ancient ABI.)

So it's going to take some time - sorry.

Ross

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL packaging on Debian

[Ross Vandegrift]

On Fri, Oct 14, 2016 at 09:58:39AM +0200, Stefan Schmidt wrote:
> I just did my monthly round to update our packaging status and happily 
> saw that your packaging for efl 1.18.1 and e 0.21.2 hit experimental. 
> Congrats and thanks for your persistent work on getting this moved forward!

Thanks Stefan!

Ross

--
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] EFL packaging on Debian

[Ross Vandegrift]

On 09/13/2016 07:07 PM, Stefan Schmidt wrote:
> On 14/09/16 00:13, Ross Vandegrift wrote:
>> On 09/13/2016 05:58 PM, Stefan Schmidt wrote:
>> The current Debian maintainer has been missing, but supposedly returning
>> soon.
>
> Soon as in this year?

Yep, that's what I've heard - of course people's plans change, so who 
knows for sure.

>> Soon, I hope we'll be able to get these into the archive.
>
> I have seen you mention this before and I wonder how realistic this hope
> is. Are you a Debian Developer or maintainer? Do you have a sponsor that
> would sponsor your non packager uploads?

No, I am not a DD or DM.  But I think I could find a sponsor.  I've been 
waiting for Albin - he's expressed interest to me to be involved, and 
I'd like to wait.  But if it doesn't pan out, I don't think it's the end 
of the road.

I think your pessimism is fair, but hope to help improve the situation.

>> Hypothesis: E17 on EFL 1.8 might be old, but it's reasonably stable and
>> useful.  So end-users that do not follow EFL development might not
>> know/care about new features.  Those that do probably build from source.
>
> You think these users do also not care about bug fixes and security
> fixes? You know many people that are using efl 1.8 and e17 and are happy
> that Debian does not update to newer versions?

Oh I don't think anyone is happy about it - I haven't been.  But that 
doesn't mean it's been impossible to get by.

 > I talk about Debian unstable here and not some years old
 > release. (I have been using Debian SID myself for over 10 years and
 > at that point packages have been updated when new versions came out)

If you have time and interest, I'd be happy to get bug/success reports 
on the packages so far.

Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL packaging on Debian

[Ross Vandegrift]

On 09/13/2016 05:58 PM, Stefan Schmidt wrote:
> I guess you would need to ask the Debian packagers to update or find new 
> ones wanting to keep up with the work. To me the maintainers seem to be 
> missing in action and so far everybody stepped up to replace them. Part 
> of the problem is that interested folks might not be a Debian 
> maintainers and would need a sponsor. I tried to arrange for this with a 
> Debian Developer I knew but even for the sponsor its a lot work so it 
> did not pan out.

The current Debian maintainer has been missing, but supposedly returning
soon.  In the meantime, I've been maintaining updated Debian packaging
in the debian/sid branch of:
  https://github.com/rvandegrift/efl
  https://github.com/rvandegrift/e

Soon, I hope we'll be able to get these into the archive.

> If you compare this to other mainstream distros like OpenSUSE or Fedora 
> which ship really up to date packages I can't really see why our code is 
> not interesting for debian while it is for other distros. But given how 
> long we have this situation I think we might have to face it that this 
> will not change.

Hypothesis: E17 on EFL 1.8 might be old, but it's reasonably stable and
useful.  So end-users that do not follow EFL development might not
know/care about new features.  Those that do probably build from source.

Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL sonames

[Ross Vandegrift]

On November 4, 2015 7:48:53 PM EST, Carsten Haitzler
<ras...@rasterman.com> wrote:
>On Wed, 04 Nov 2015 11:54:43 -0500 Ross Vandegrift <r...@kallisti.us>
>said:
>
>> Hi all,
>> 
>> Is there an official stance on sonames in EFL & friends?  I see some
>> discussion about this in the archives circa 2009, but it looks like
>> plans changed.  See the thread starting at [1].
>> 
>> I'd like to get the Debian packages updated, and I'm just trying to
>> figure out what to expect on this front.
>
>our stance is - you DONT CHANGE OUR SONAMES OR SO MAJOR VERSIONS. do
>not
>change. leave. don't patch.
>
>we did this pre 1.0 because we broke api/abi "at will" pre 1.0.
>
>you also don't change our pkgconfig pc file names or the names of
>header
>files, nor the names of dirs underneath PREFIX/xxx where xxx is bin,
>lib,
>include, share, etc ... :) i.e.
>
>we have things installed in libdir/evas where libdir may
>be /usr/lob, /usr/lib64, /usr/local/lib, /opt/whatever/lib or maybe
>even /usr/lib/i386-linux ... that we allow. all of these dirs MUSt
>share a
>prefix. ie
>
>/usr or /usr/local or /opt/blah etc. - don't move stuff OUT of prefix
>EXCEPT
>etc. that's allowed. :)
>
>does this help?

Err, not really - I was wondering about when you guys would change a
soname.  Sorry for being unclear.

Looking over the history, I'd guess the plan is to leave them alone.
But maybe an EFL 2.x would trigger a change?  I'm not 100% confidant of
that assessment.  Just trying to figure out what to expect.

Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] EFL sonames

[Ross Vandegrift]

Hi all,

Is there an official stance on sonames in EFL & friends?  I see some
discussion about this in the archives circa 2009, but it looks like
plans changed.  See the thread starting at [1].

I'd like to get the Debian packages updated, and I'm just trying to
figure out what to expect on this front.

Thanks,
Ross

[1] -
https://www.mail-archive.com/enlightenment-devel%40lists.sourceforge.net/msg21183.html

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 1.15.2 Planned for Thursday Next Week (Oct. 1)

[Ross Vandegrift]

On 10/20/2015 05:15 AM, Stefan Schmidt wrote:
> Hello.
> 
> On 26/09/15 17:05, Ross Vandegrift wrote:
>> On 09/21/2015 04:13 AM, Daniel Juyung Seo wrote:
>>> I am planning to release 1.15.2 next Thursday afternoon in GMT. (Oct.
>>> 1) If you have any more backports that need to be pushed into the
>>> stable release, please merge them to 1.15 branch by Wednesday noon in
>>> GMT.
>> Are you interested in fixes required for strict linking (-Wl,-z,defs)?
>> If so, I need to cherry-pick 99c0c1cb from master and apply the two
>> patches pasted below.
>>
>> Thanks,
>> Ross
>>
>>
>> --- a/src/lib/ecore_fb/ecore_fb_private.h
>> +++ b/src/lib/ecore_fb/ecore_fb_private.h
>> @@ -33,6 +33,20 @@
>>
>>   #include 
>>
>> +#ifdef EAPI
>> +# undef EAPI
>> +#endif
>> +
>> +#ifdef __GNUC__
>> +# if __GNUC__ >= 4
>> +#  define EAPI __attribute__ ((visibility("default")))
>> +# else
>> +#  define EAPI
>> +# endif
>> +#else
>> +# define EAPI
>> +#endif
>> +
>>   /* ecore_fb_li.c */
>>   struct _Ecore_Fb_Input_Device
>>   {
>> @@ -92,4 +106,7 @@
>>   #define TS_GET_CAL 0x8014660a
>>   #endif
>>
>> +#undef EAPI
>> +#define EAPI
>> +
>>   #endif
>>
>>
>>
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1107,6 +1107,10 @@
>>
>>   EFL_CHECK_LIBS([EMILE], [zlib])
>>
>> +if test "x${want_liblz4}" = "xyes" ; then
>> +   EFL_DEPEND_PKG([EMILE], [LIBLZ4], [liblz4])
>> +fi
>> +
>>   EFL_INTERNAL_DEPEND_PKG([EMILE], [eina])
>>
>>   EFL_EVAL_PKGS([EMILE])
>>
> 
> Is this problem solved for you?

I haven't had a chance to look at the new release yet.  If these issues
are still hanging out when I do, I'll drop a note to the list.

Thanks,
Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 1.15.2 Planned for Thursday Next Week (Oct. 1)

[Ross Vandegrift]

On 09/21/2015 04:13 AM, Daniel Juyung Seo wrote:
> I am planning to release 1.15.2 next Thursday afternoon in GMT. (Oct.
> 1) If you have any more backports that need to be pushed into the
> stable release, please merge them to 1.15 branch by Wednesday noon in
> GMT.

Are you interested in fixes required for strict linking (-Wl,-z,defs)?
If so, I need to cherry-pick 99c0c1cb from master and apply the two
patches pasted below.

Thanks,
Ross


--- a/src/lib/ecore_fb/ecore_fb_private.h
+++ b/src/lib/ecore_fb/ecore_fb_private.h
@@ -33,6 +33,20 @@

 #include 

+#ifdef EAPI
+# undef EAPI
+#endif
+
+#ifdef __GNUC__
+# if __GNUC__ >= 4
+#  define EAPI __attribute__ ((visibility("default")))
+# else
+#  define EAPI
+# endif
+#else
+# define EAPI
+#endif
+
 /* ecore_fb_li.c */
 struct _Ecore_Fb_Input_Device
 {
@@ -92,4 +106,7 @@
 #define TS_GET_CAL 0x8014660a
 #endif

+#undef EAPI
+#define EAPI
+
 #endif



--- a/configure.ac
+++ b/configure.ac
@@ -1107,6 +1107,10 @@

 EFL_CHECK_LIBS([EMILE], [zlib])

+if test "x${want_liblz4}" = "xyes" ; then
+   EFL_DEPEND_PKG([EMILE], [LIBLZ4], [liblz4])
+fi
+
 EFL_INTERNAL_DEPEND_PKG([EMILE], [eina])

 EFL_EVAL_PKGS([EMILE])

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl and Elementary 1.14.1 release

[Ross Vandegrift]

On 06/14/2015 11:43 PM, Jean-Philippe André wrote:
 On Sun, Jun 14, 2015 at 10:31 PM, Ross Vandegrift r...@kallisti.us wrote:
 The gen_shaders.sh output is missing from the tarball, and the script
 won't regen if it's not in a git tree.  I modified the script to disable
 change detection, and everything worked fine.  git works.

 
 Do you mean evas_gl_shaders.x and evas_gl_enums.x are missing?
 I can find them in the tree after make dist... It also builds fine.

Yes, make barfs on files that include them.  They are there originally,
but it looks like they got nuked when I ran make clean:

ross@vanvanmojo:~/src/e/efl-1.14.1$ nice make
make --no-print-directory all-recursive
Making all in src
  SHADERS  modules/evas/engines/gl_common/shader_3d/evas_gl_3d_shaders.x
make  all-recursive
  SHADERS  modules/evas/engines/gl_common/shader_3d/evas_gl_3d_shaders.x
  CC
modules/evas/engines/gl_common/modules_evas_engines_gl_common_libevas_engine_gl_common_la-evas_gl_3d_shader.lo
modules/evas/engines/gl_common/evas_gl_3d_shader.c:2:42: fatal error:
shader_3d/evas_gl_3d_shaders.x: No such file or directory
 #include shader_3d/evas_gl_3d_shaders.x
  ^
compilation terminated.
Makefile:26282: recipe for target
'modules/evas/engines/gl_common/modules_evas_engines_gl_common_libevas_engine_gl_common_la-evas_gl_3d_shader.lo'
failed
make[4]: ***
[modules/evas/engines/gl_common/modules_evas_engines_gl_common_libevas_engine_gl_common_la-evas_gl_3d_shader.lo]
Error 1
Makefile:33817: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
Makefile:11923: recipe for target 'all' failed
make[2]: *** [all] Error 2
Makefile:2437: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:1582: recipe for target 'all' failed
make: *** [all] Error 2


 The docs failed to build because preview_text_filter won't link.  Not
 obvious why, so I disabled them.  In this case, same failure from git.

 What was the error message?
 
 What platform are you building for? Linux? Which distrib then?

The linker was unable to find a dozen or so efl_gfx_XXX symbols, but I
can't reproduce this issue anymore.  I think it must've either been an
artifact of a weird build while troubleshooting the above, or else it's
better now that I have EFL 1.14 installed.

(FWIW, I'm in a Debian jessie chroot, for a non-/usr prefix.)

Ross

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Efl and Elementary 1.14.1 release

[Ross Vandegrift]

On 06/02/2015 06:31 AM, Daniel Juyung Seo wrote:
 1.14.1 is released!
 This is the first update for the 1.14.x series.
 
 Efl fixes:
[snip]
* Evas GL common: Skip shaders generation if there is no change

Two minor issues in the 1.14.1 release:

The gen_shaders.sh output is missing from the tarball, and the script
won't regen if it's not in a git tree.  I modified the script to disable
change detection, and everything worked fine.  git works.

The docs failed to build because preview_text_filter won't link.  Not
obvious why, so I disabled them.  In this case, same failure from git.

Ross


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

On Wed, 2012-06-27 at 13:07 +0100, Michael Blumenkrantz wrote:
 tried again, still can't reproduce

Hmmm, any idea what I could look at?  I can reproduce on my workstation
and laptop, in a normal X session or Xephyr, with a fresh profile or an
existing one.  I pulled 72968 to check, and it is still there.

In case it matters: Xorg 1.12.1902 (Debian testing), no OpenGL, no
non-stock E17 modules.



Different issue: pager squishes all my virtual desktops so they are
super-skinny, even though the whole is still as wide as it normally is:
http://www.enlightenment.org/ss/e-4fec46bb7882e9.74897488.jpg

I can fix it by changing the number of virtual desktops, and then
changing it back.

Ross

 
 On Wed, Jun 27, 2012 at 12:45 PM, Ross Vandegrift r...@kallisti.us wrote:
 
  On Thu, 2012-06-21 at 12:46 +0100, Michael Blumenkrantz wrote:
   On Thu, Jun 21, 2012 at 12:07 PM, Ross Vandegrift r...@kallisti.us
  wrote:
Window autoraise doesn't work with sloppy focus:
   
1) Same focus settings as above, plus window autoraise.
2) Open two overlapping windows on a virtual desktop.
3) Position the pointer in the area were they overlap.
4) Flip to a different virtual desktop, and then back.
5) The windows autoraise over one another forever.
   
  
   also doesn't happen here
 
  I still see this on 72833, and can reproduce it with a fresh profile:
 
  1) Create a new user, go through first-time setup wizard.
  2) In Settings - Windows - Window Stacking, enable Raise windows on
  mouse over.
  3) Open two windows which overlap as described above.
  4) Position the mouse in their intersection.
  5) Use keyboard to flip to different virtual desktp, and then back.
  6) Autoraising forever.
  7) Anything with manually forces focus changes returns things to normal.
 
  Sorry - just realized I wasn't clear that 5 requires flipping via the
  keyboard.
 
  Ross
 
 
  --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

On Thu, 2012-06-21 at 12:46 +0100, Michael Blumenkrantz wrote:
 On Thu, Jun 21, 2012 at 12:07 PM, Ross Vandegrift r...@kallisti.us wrote:
  Window autoraise doesn't work with sloppy focus:
 
  1) Same focus settings as above, plus window autoraise.
  2) Open two overlapping windows on a virtual desktop.
  3) Position the pointer in the area were they overlap.
  4) Flip to a different virtual desktop, and then back.
  5) The windows autoraise over one another forever.
 
 
 also doesn't happen here

I still see this on 72833, and can reproduce it with a fresh profile:

1) Create a new user, go through first-time setup wizard.
2) In Settings - Windows - Window Stacking, enable Raise windows on
mouse over.
3) Open two windows which overlap as described above.
4) Position the mouse in their intersection.
5) Use keyboard to flip to different virtual desktp, and then back.
6) Autoraising forever.
7) Anything with manually forces focus changes returns things to normal.

Sorry - just realized I wasn't clear that 5 requires flipping via the
keyboard.

Ross


signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

On Mon, 2012-06-25 at 08:50 +0100, Michael Blumenkrantz wrote:
 okay, fixed.

Works perfectly now - thanks!

Ross


signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

(sorry if this doubles up - thought I replied to this last night...)

On Thu, 2012-06-21 at 01:51 +0800, P Purkayastha wrote:
 You will hate my bugs, but you asked for it ;-)
 
 To reproduce (my configuration):
 - Set window focus:
  sloppy
  all new windows get focus
  all options ticked under Window Focus - advanced - miscellaneous
 - EFM is unloaded (so, no desktop icons, etc)
 
 
 Bug 1: (Lost key input)
 - Close a window using keybindings, for instance, Ctrl-d on a terminal, 
 so that the pointer is on the desktop after the window is closed
 - E stops accepting all key input (for example try alt-tab, alt-esc, etc)
 - You can make E start re-accepting key input by focusing on or opening 
 a new window
 
 Status:
 - Has been around for about a year.
 - Very hard to reproduce
 - But experience at least once daily

When input is dead like this, if you type letters, do they appear on the
desktop?  I hit a similar version, but I can't tell if it's a bug:

1) Open a window.
2) Flip to a virtual desktop with no open windows.
3) Type some chars.  They appear on the desktop and don't seem to do
anything.
4) Pressing escape returns behavior to normal.




Window autoraise doesn't work with sloppy focus:

1) Same focus settings as above, plus window autoraise.
2) Open two overlapping windows on a virtual desktop.
3) Position the pointer in the area were they overlap.
4) Flip to a different virtual desktop, and then back.
5) The windows autoraise over one another forever.


There's a few crash bugs I hit.  This one is a particular pain, but I've
been unable to track down better info on what's causing it:

1) Compose a new email in Evolution.
2) Type some things, maybe put some recipients.
3) Close the messages and choose to discard it when asked.
4) E crashes.

Unfortunately, it looks like there's some tight timing issue - running
under valgrind makes it impossible to reproduce...

Ross



signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

On Thu, 2012-06-21 at 07:48 +0100, Michael Blumenkrantz wrote:
 tested here, works fine. invalid.

Hmmm - perhaps it is more specific then?

I have a shelf in the lower right that contains only the systray
module, and is set to autohide.  Four apps have icons there: network
manager, bluetooth, tomboy, and vino.  Here's my exact steps that do it
everytime:

1) Click tomboy icon to open the menu of notes.
2) Select a note from the list.  The menu closes, the note opens.
3) The shelf stays visible until I move the pointer in and back out.

Perhaps the open menu is important?  The pointer leaves the shelf
window via the tomboy menu, and the click which closes that menu isn't
within the shelf.

Ross




 
 On Thu, Jun 21, 2012 at 5:00 AM, Ross Vandegrift r...@kallisti.us wrote:
 
  On Wed, 2012-06-20 at 23:35 +1000, David Seikel wrote:
   On Wed, 20 Jun 2012 08:18:04 -0500 Jeff Hoogland
   jeffhoogl...@linux.com wrote:
Any chance we can make the systray less of a red headed step child?
  
   The systray spec is a red headed step child by design.  Not our
   fault, but some of us try to support that crap as well as we can.  The
   rest of us try to pretend it never existed.
 
  Systray module breaks shelf auto-hide.
 
  On mouse-out of a shelf with a systray, the shelf doesn't autohide if
  the mouse-out happened through a window created by a systray element -
  it is as if the shelf never gets the even that the pointer left the
  window.
 
  Ross
 
 
  --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond. Discussions 
 will include endpoint security, mobile security and the latest in malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

On Thu, 2012-06-21 at 20:33 +0800, P Purkayastha wrote:
 No, nothing appears on the desktop. Mainly because I don't use desktop 
 icons and I keep the file manager module unloaded. However, I do know 
 that pressing escape doesn't help in my case.
 
 Your case actually sounds like a problem with efm.

Yep, you're right: if I disable efm, then no typing on the desktop.

Ross


signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E17 BUG CALL

[Ross Vandegrift]

On Wed, 2012-06-20 at 23:35 +1000, David Seikel wrote:
 On Wed, 20 Jun 2012 08:18:04 -0500 Jeff Hoogland
 jeffhoogl...@linux.com wrote:
  Any chance we can make the systray less of a red headed step child?
 
 The systray spec is a red headed step child by design.  Not our
 fault, but some of us try to support that crap as well as we can.  The
 rest of us try to pretend it never existed.

Systray module breaks shelf auto-hide.

On mouse-out of a shelf with a systray, the shelf doesn't autohide if
the mouse-out happened through a window created by a systray element -
it is as if the shelf never gets the even that the pointer left the
window.

Ross


signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] last call for efm mount bugs

[Ross Vandegrift]

On Fri, 2012-06-15 at 08:06 +0100, Michael Blumenkrantz wrote:
 #2 and #3 appear to be fixed as well with a current build using both eeze
 and udisks.

Sweet - updated again, looking good.

Thanks,
Ross


signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] last call for efm mount bugs

[Ross Vandegrift]

On Wed, 2012-06-13 at 07:37 +0100, Michael Blumenkrantz wrote:
 you've all got until this friday to notify me of any remaining efm mount
 bugs. after that I'm switching gears and probably won't be working on it
 for a bit.

Just this week I tried switching to EFM for accessing USB media.  Using
SVN 71790:

1) I plug in a USB flash drive.  It appears on the desktop with the M
icon.  When I double-click it, the EFM window shows no files.  If I hit
refresh, the files show up.

2) Insert a USB flash drive with multiple partitions (Debian USB
install stick) and then Eject it.  Rather then go away, both icons
remain, labeled with their filenames: |sdd_1.desktop,
|sdd_2.desktop.  To fix this requires disabling and re-enabling the
display of device icons.

3) After I have the icons in the broken state from #2, insert a normal
USB flash drive.  One icon changes to indicate that it is mounted.  No
name change.  No result if I click it.  After the fix in #2, things
works as they did in #1 again.

Ross


signature.asc
Description: This is a digitally signed message part
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Evolution crashes Enlightment?

[Ross Vandegrift]

On Mon, 2011-10-24 at 18:36 -0400, Ross Vandegrift wrote:
 Anyone else use Evolution under E?  I have recently been plagued by a
 very annoying bug.  Sometimes if I close a compose window, Enlightenment
 freezes.  It's a weird freeze - mouse is fine but no new windows can be
 drawn.  (Here, I mean something like X11 windows, not app windows:
 Evolution continues to work, so long as I resist doing anything that
 opens a menu).
 
 Nothing in my ~/.xsession-errors.  No white box.  strace shows it
 waiting on a futex.  gdb reports that it is unable to get a backtrace
 due to a corrupt stack frame.

Got some glibc double-free info this time.  I'd love it if this helps,
but I don't really know what to look for in here.

Ross




*** glibc detected *** /usr/local/bin/enlightenment: double free or corruption 
(!prev): 0x089f6be0 ***
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6aac1)[0xb72b5ac1]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c328)[0xb72b7328]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb72ba3dd]
/usr/local/bin/enlightenment[0x8083cf2]
=== Memory map: 
08048000-0816c000 r-xp  08:11 670442 /usr/local/bin/enlightenment
0816c000-0816e000 rw-p 00123000 08:11 670442 /usr/local/bin/enlightenment
0816e000-08174000 rw-p  00:00 0 
087c2000-08ff7000 rw-p  00:00 0  [heap]
b16ed000-b180 rw-s  00:04 979730444  /SYSV (deleted)
b180-b1861000 rw-p  00:00 0 
b1861000-b190 ---p  00:00 0 
b1918000-b1d0 r--p  08:11 796355 
/usr/share/fonts/truetype/unfonts-core/UnDotumBold.ttf
b1d0-b1dec000 rw-p  00:00 0 
b1dec000-b1e0 ---p  00:00 0 
b1eff000-b1f0 r--s  08:12 2108764
/home/ross/.e/e/applications/menu/favorite.menu
b1f0-b1fe rw-p  00:00 0 
b1fe-b200 ---p  00:00 0 
b205-b2073000 rw-s  00:04 980156496  /SYSV (deleted)
b2073000-b2074000 ---p  00:00 0 
b2074000-b2874000 rw-p  00:00 0 
b2874000-b2875000 ---p  00:00 0 
b2875000-b3075000 rw-p  00:00 0 
b3075000-b3076000 ---p  00:00 0 
b3076000-b3876000 rw-p  00:00 0 
b3876000-b3877000 ---p  00:00 0 
b3877000-b4942000 rw-p  00:00 0 
b4942000-b4949000 r-xp  08:11 675025 
/usr/local/lib/libexchange.so.0.0.0
b4949000-b494a000 rw-p 7000 08:11 675025 
/usr/local/lib/libexchange.so.0.0.0
b494a000-b494c000 rw-p  00:00 0 
b494c000-b4953000 r-xp  08:11 3980   
/usr/local/lib/enlightenment/modules/conf_wallpaper2/linux-gnu-i686-ver-pre-svn-08/module.so
b4953000-b4954000 rw-p 6000 08:11 3980   
/usr/local/lib/enlightenment/modules/conf_wallpaper2/linux-gnu-i686-ver-pre-svn-08/module.so
b4962000-b496a000 r--s  08:12 2632062
/home/ross/.cache/efreet/icons___efreet_fallback_vanvanmojo.kallisti.us.eet 
(deleted)
b496a000-b4a37000 r--s  08:12 2626754
/home/ross/.cache/efreet/icons_gnome_vanvanmojo.kallisti.us.eet (deleted)
b4a37000-b4a3e000 r--s  08:12 2631800
/home/ross/.cache/efreet/icon_themes_vanvanmojo.kallisti.us.eet (deleted)
b4a5b000-b4a7 r-xp  08:11 3977   
/usr/local/lib/enlightenment/modules/fileman/linux-gnu-i686-ver-pre-svn-08/module.so
b4a7-b4a71000 rw-p 00015000 08:11 3977   
/usr/local/lib/enlightenment/modules/fileman/linux-gnu-i686-ver-pre-svn-08/module.so
b4a88000-b4a97000 r--p  08:11 791882 
/usr/share/fonts/truetype/mathematica/VeraBd.ttf
b4a97000-b4c6c000 rw-p  00:00 0 
b4c7d000-b4ca rw-s  00:04 980123727  /SYSV (deleted)
b4ca-b4cb9000 rw-s  00:04 980090958  /SYSV (deleted)
b4cb9000-b4cbb000 r--s  08:11 397773 
/var/lib/menu-xdg/menus/debian-menu.menu
b4cc8000-b4ce1000 rw-s  00:04 980058188  /SYSV (deleted)
b4ce1000-b4cef000 rw-s  00:04 980025419  /SYSV (deleted)
b4cef000-b4cf1000 r--s  08:11 397773 
/var/lib/menu-xdg/menus/debian-menu.menu
b4cfb000-b4d04000 rw-s  00:04 979992648  /SYSV (deleted)
b4d04000-b4d9a000 r--p  08:11 799768 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Oblique.ttf
b4d9a000-b4deb000 r--p  08:11 793455 
/usr/share/fonts/truetype/msttcorefonts/Times_New_Roman.ttf
b4ded000-b4dff000 r--p  08:11 792814 
/usr/share/fonts/truetype/ttf-tamil-fonts/TSCu_paranari.ttf
b4dff000-b4e0f000 r--p  08:11 792173 
/usr/share/fonts/truetype/ttf-tamil-fonts/TSCu_Paranar.ttf
b4e0f000-b4e24000 r--p  08:11 792802 
/usr/share/fonts/truetype/ttf-tamil-fonts/TSCu_paranarb.ttf
b4e24000-b4e6a000 r--p  08:11 793461 
/usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
b4e6a000-b4e74000 r-xp  08:11 413017 
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so
b4e74000-b4e75000 r--p 9000 08:11 413017 
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so

Re: [E-devel] gnome-terminal exit code

[Ross Vandegrift]

On Fri, 2011-10-21 at 21:27 +0200, Sebastian Dransfeld wrote:
 Why does gnome-terminal exit with code 255 when executed from the menu 
 in E, but not when executed from a terminal?

Bug in gnome-terminal, has nothing to do with menu launching.  See:
https://bugzilla.gnome.org/show_bug.cgi?id=646317
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633979

Ross
-- 
Ross Vandegrift r...@kallisti.us


signature.asc
Description: This is a digitally signed message part
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Why is the order of 'task-switching' (alt+tab) so bewildering in e17 (and e16) -- Bug or Feature??

[Ross Vandegrift]

On Tue, Nov 17, 2009 at 06:38:25PM +1100, Carsten Haitzler wrote:
 for those that love alt-tab, it tends to be mutually exclusive to
 pointer/sloppy focus - so use click to focus. 

FWIW, I disagree with that.  I've been using sloppy focus follows
mouse with alt-tab for years now and have never had a problem.  It
works great!

Ross

-- 
Ross Vandegrift
r...@kallisti.us

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie


signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Recursive CCing? Was: Choice of a Window Manager

[Ross Vandegrift]

On Tue, Oct 13, 2009 at 06:42:22AM +1000, David Seikel wrote:
 Thirdly, and this is most important, STOP CCINC ME, IM ON THE DAMN
 LIST
 
 As a programmer I don't like to see duplicate code.
 
 Please don't CC me any replies to things I say on the list.  I'm on the
 list and will see it anyway.

Then turn on de-duplication in mailman for the mailing list.  Every
message has a link at the bottom to the Mailman preferences.  You want
to turn on Avoid duplicate copies of messages.  This will prevent
mailman from sending you copies of messages where you appear in the To
or CC field.


As a programmer, you'll appreciate the reasons why senders cannot
effectively determine when or when not to CC:

First, and foremost, a responder has no clue if a CCed address is a
list member or not.  Since generally, we want unrelated developers to
be able to participate in discussions on mailing lists they don't
subscribe to, CCs should be permitted. (for example, CCing a relevant
Xorg developer on a question between E and X interaction could be
important - you don't want to force such third parties to subscribe to
the list).

Second, some people (like me) sometimes prefer to get CCs to my
messages.  For some lists, I filter the list into a folder, but CCs
go into my inbox.  This flags me when someone responds to *me*.

Third, the relatively well-established mailing list management
methodology (at least among free software development mailing lists)
is to Reply-To-All and let individual preference settings shake out
how mail actually gets delivered.  The mailing list is for listing
members - it should not enfore delivery policy.

Ross

-- 
Ross Vandegrift
r...@kallisti.us

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie


signature.asc
Description: Digital signature
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] notification module: how do you use it?

[Ross Vandegrift]

On Tue, May 12, 2009 at 11:24:00PM -0300, Gustavo Sverzut Barbieri wrote:
 if you use it: do you use the box/gadget feature? This is about half
 of the code, I never used it or found a use for it, when I tried it it
 seems broken. So I rather drop this instead of trying to fix. What do
 you think? Anyone strongly against it? If not I'll drop this feature,
 fix some bugs with popup positioning and move it to e/src/modules.

Your message spurned me to try it out!  I just played around with it,
and at first blush, the gadget version seems much better to me - the
shelf version leaves empty space on my shelf which is kind of
unsightly.

But being half the code, I could always create new transparent
shelves.  Always trade-offs. :)

-- 
Ross Vandegrift
r...@kallisti.us

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Autohide shelf function not working correctly

[Ross Vandegrift]

On Tue, Mar 24, 2009 at 11:05:03AM +0100, Luca De Marini wrote:
 Hallo people, this post is because I'm having problems with the shelves. I'm
 running the E17 version compiled by quaker, so it's not the latest version.
 I need to know if you experienced my problem in previous versions of E or if
 you are experiencing problems now or maybe you didn't notice..
 
 So, my problem is that when I activate the autohide function:
 
 1) On mouseover, the shelf doesn't show at all. Madnessmike tested it too,
 same result. I tested it with my theme but also with the default theme and
 others, same result, it does not appear. In the past, it used to.
 
 2) On mouse click, even clicking next to the shelf, the E menu comes out.
 Going completely on the edje of the screen and clicking, the shelf appears
 only after some seconds and then it disappears only if I'm over it.
 Sometimes it appears immediately but yet it doesn't stay there untill I move
 my mouse away, it goes away after some seconds, randomly.

I ran into a similar-sounding shelf weirdness with auto-hide a few
months ago.  I fixed it by adding an extra shelf - the broken behavior
moved the new shelf, which I then deleted.

I have no idea why.  The thread is at:
http://www.mail-archive.com/enlightenment-us...@lists.sourceforge.net/msg12422.html

Ross

-- 
Ross Vandegrift
r...@kallisti.us

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Being social...

[Ross Vandegrift]

On Tue, Mar 24, 2009 at 01:40:25PM +0100, Siemen Baader wrote:
 While I totally agree, I think people get hooked better on e if they
 could actually go on trying e17. I personally wanted to try it for I
 think 4 years now, but it was just so much easier to '$ sudo apt-get
 install xfce4' on my box, so I didn't bother.

This is definitely true - I've recruited almost a dozen E fanatics
at work just by running it!  People get very curious when they see how
different the visuals are.  People's minds are blown when they see me
switch desktops separately on each head or flip the mouse cursor over
to the other via the keyboard.  And of course, once they switch, they
rarely go back :)

-- 
Ross Vandegrift
r...@kallisti.us

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Little problem with ETK

[Ross Vandegrift]

On Fri, Nov 14, 2008 at 10:26:54PM +0100, Matteo wrote:
 I've added the /opt/e17/lib/pkgconfig in the pkg_config_path so now if I do:
 
 echo $PKG_CONFIG_PATH
 /opt/e17/lib/pkgconfig/:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
 
 is it right? Because if I launch in the ewl source dir the ./configure
 commands, it give me the same error:

Check if /opt/e17/lib/pkgconfig/evas.pc exists.  If it doesn't, it's
possible that your evas installation isn't complete or that you
installed evas into a different prefix.

If it does, you may need to export PKG_CONFIG_PATH before running
configure.

Ross


-- 
Ross Vandegrift
[EMAIL PROTECTED]

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Announce] Edgar + Places

[Ross Vandegrift]

On Fri, Nov 07, 2008 at 08:52:16PM +0100, Dave Andreoli wrote:
 You can find all the new stuff at
 http://code.google.com/p/e17mods/
 
 The new modules are Places and Edgar (plus some new gadgets for edgar).
 
 Hope you like the work...and wait for suggestions.

Hi Dave,

I just downloaded Places and installed it.  A few bugs:

1) When I click a Place from the Enlightenment menu, nothing happens

2) If I add the Places gadget to a shelf, removing it or the module
causes E to crash.

Looks good though!

Thanks,
Ross

-- 
Ross Vandegrift
[EMAIL PROTECTED]

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Entrance and network manager not working

[Ross Vandegrift]

On Fri, Oct 31, 2008 at 08:21:04AM +0100, Luca De Marini wrote:
 In any case, now my situation is quite weird.
 If I log in with the session enlightenment, I have  a normal E session and
 NM does not working.
 But if I log in to a default session, enlightenment has Nm support!!
 What's weird is that I deleted the .xsession file you told me to create,
 more than that, shouldn't the default session be the last one I used and
 configured to be default, that is, in my case, enlightenment? What's
 different between the enlightenment and default session? Do you have any
 idea why one session gives me NM support and the other one not? I believed
 that the problem was dbus, but with my script it should be running... still
 I can't get what has the default session more than the enlightenment one...
 
 Greetings everyone and thanks for your help in this :)

It sounds like your needs a little more advanced than my solution,
which is good for one user but not for many.

To understand how display manager startup happens, here's what you'll
want to read:

1) the shell scripts in /etc/X11/Xsession and /etc/X11/Xsession.d
2) the desktop files in /usr/share/xsession and/or
/usr/local/share/xsession.

Read through them and you'll start to understand what it means when
GDM/entranced provides an option to login to Gnome, KDE, or
Enlightenment.

It sounds like what you want is to make a new desktop session file,
maybe Luca's Desktop, that executes the specific things you want to
provide to your users.


-- 
Ross Vandegrift
[EMAIL PROTECTED]

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Geubuntu-dev] Pidgin lagging or using too much resources

[Ross Vandegrift]

On Thu, Oct 30, 2008 at 07:33:02AM -0600, Jorge Mariani wrote:
 I have a Dell Precision M4300, CoreDuo, 4GB RAM, two disks (40GB Solid  
 State, 80GB SATA), and nVidia Quadro FX360M.
 I have installed Ubuntu Server with LAMP.
 I usually run Firefox 3.0.3 with Firebug, Scite or Bluefish, Pidgin,  
 and sometimes GIMP.

[snip]

 I navigated the whole internet looking for solutions, and none worked,  
 until I found an article talking about GMail messaging and having  
 issues with that. So, i disabled GMail from Pidgin (I only have Luca  
 connected) and then voila, freezing is no longer happening, and the  
 machine is usable again (besides the fact Firefox still eats round 40%  
 CPU when scrolling a page).

Noting that your video card is nvidia and you're seeing slow
scrolling, you're probably using the nv open source driver.

If this is correct, you're likely experiencing software glyph and
compositing issues from Xorg.  You'll notice this happens in varying
degress when Gecko renders layers of translucent images.  The more
layers to blend the worse it get.

Check if nouveau, the experimental accelerated driver, supports your
chipset.  If so, you should experience quite better performance.  I'm
using nouveau with a G7x card and Enlightenment.

Ross

--
Ross Vandegrift
[EMAIL PROTECTED]

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] entraced freezes up

[Ross Vandegrift]

Hey,

Has anyone done any debugging on entraced freezing up after sitting
idle at a login screen for a while?

I can reproduce it easy enough, but haven't bolted strace/gdb on to
peek under the hood yet.  Took easy to zap the Xserver and get a fresh
login box :).

Just curious!

-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Network Manager

[Ross Vandegrift]

On Wed, May 07, 2008 at 09:51:05PM +0200, Stefan Schmidt wrote:
 On Tue, 2008-05-06 at 17:36, Ross Vandegrift wrote:
  On Tue, May 06, 2008 at 09:27:07PM +0200, The DarkMaster wrote:
   Hallo, I'm very interested in this topic and an E17 network manager is
   really needed by my OpenGEU distro too. Well, I believe taht a good choice
   would be that of using Network Manager from Gnome:
   http://www.gnome.org/projects/NetworkManager/
  
  Since I started working on e_nm, Stefan has contributed a number of
  patches to the infrastructure for it.  A proof-of-concept that
  doesn't do much of anything with that library is at
  http://kallisti.us/~ross/enetmgr-0.1.tar.gz
 
 Cool. Motivation push. People really using it. ;)

Hah - I actually hacked through the crashes I found in NM this past
weekend and have a custom NetworkManager running that fixes my issues.
I tried picking up my demo code, but it looks like E_Nm is pretty
different than the way I remember it :).

Stefan - IIRC, you sent in some patches for E_Nm after I did.  It
looks like the general idea is that there's structures recording the
state of various NM things (devices, networks, APs, etc).

I'm concerned because some of the comments indicate E_Nm's API is
taken from NetworkManager 0.7 - is that correct?  0.6 seems to be the
version included in all the distros, and attempting to upgrade to 0.7
was a miserable, miserable thing.

Is the 0.6 API still in there?



  I have some updates to it that don't even build against current libe_nm.
 
 I also have to update it to some newer API changes.
 
 Besides that I have a lot stuff in some hacky patches that are to ugly
 for upstream. I need to sit down, sort things out and push them out
 for review.
 
 regards
 Stefan Schmidt



 -
 This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
 Don't miss this year's exciting event. There's still time to save $100. 
 Use priority code J8TL2D2. 
 http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Network Manager

[Ross Vandegrift]

On Tue, May 06, 2008 at 09:27:07PM +0200, The DarkMaster wrote:
 Hallo, I'm very interested in this topic and an E17 network manager is
 really needed by my OpenGEU distro too. Well, I believe taht a good choice
 would be that of using Network Manager from Gnome:
 http://www.gnome.org/projects/NetworkManager/

I agree, and started working on this a while back.  Unfortunately, I
ran into a NetworkManager crash bug that I couldn't solve and hasn't
been fixed yet.

Since I started working on e_nm, Stefan has contributed a number of
patches to the infrastructure for it.  A proof-of-concept that
doesn't do much of anything with that library is at
http://kallisti.us/~ross/enetmgr-0.1.tar.gz

I have some updates to it that don't even build against current libe_nm.

Maybe I'll have to dig back into that NM issue on my laptop...

Ross

-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current status of e_nm

[Ross Vandegrift]

On Wed, Jan 23, 2008 at 11:27:03PM +0100, Stefan Schmidt wrote:
  I'm not much of a GUI developer, but I'll try to dig up the sample
  client I was working on tonight.
 
 Thanks.

Hi Stefan,

I've posted the most recent code for my sample NM app at
http://kallisti.us/~ross/enetmgr.tar.gz

It's not currently in a state where it builds, but the tarball
includes the git history and there was an 0.1 (also on the same site,
but enetmgr-0.1.tar.gz) that did build.




-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current status of e_nm

[Ross Vandegrift]

On Tue, Jan 22, 2008 at 09:36:23PM +0100, Stefan Schmidt wrote:
 o Anybody else working on this atm? (At least a bit coordination makes
   sense sometimes. ;))

A few months back I did some work that implemented additional
functionality for E and NetworkManager. 

dbus related implementations were the big thing, and I got that
working with some additional NM related functionality.

I began work on a client application that use the EFLs to communicate
with NM.  I started with a simple EWL app that would display status,
but ran into a showstopping bug with NM on my Laptop's distro that was
causing NM to segfault when reading the status of wireless networks
via dbus.

The library code I believe was all committed to CVS.  The sample
client I started playing with is probably still on my workstation at
home, but because of the NM bug that (afaik) is still unresolved, only
really works for trivial cases like a desktop with a single wired
connection.


-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current status of e_nm

[Ross Vandegrift]

On Wed, Jan 23, 2008 at 09:26:21PM +0100, Stefan Schmidt wrote:
  with NM.  I started with a simple EWL app that would display status,
  but ran into a showstopping bug with NM on my Laptop's distro that was
  causing NM to segfault when reading the status of wireless networks
  via dbus.
 
 Do you remember which svn version from NM that was? Today I tested NM
 3302 and 425 for the gnome applet. Not the newest stuff but known to
 work quite good.
 
 I tested it with the ipw2915 wifi card in my notebook and found no
 problem so far. Connected to an open, a WEP encrypted, a WPA-PSK and a
 WPA2-PSK encrypted AP.
 
 Next step is to test this version with e_nm, get some basic
 communication running and then make my way to a newer version. Let's
 see if I can find your bug on this way. It needs to get fixed. ;)

NetworkManager itself works fine!  It's just that I've been able to
reliably crash it via calling a function over dbus.

http://bugzilla.gnome.org/show_bug.cgi?id=459323

If I query NM via dbus for info on a wireless network, NM dies.  It
can be reproduced easily via dbus-send:

dbus-send --system --print-reply --type=method_call \ 
--dest=org.freedesktop.NetworkManager \ 
/org/freedesktop/NetworkManager/Devices/eth1/Networks/SSID \
org.freedesktop.NetworkManager.Devices.getAddress

Substitute the SSID for the SSID you want to query.

  The library code I believe was all committed to CVS.  The sample
  client I started playing with is probably still on my workstation at
  home, but because of the NM bug that (afaik) is still unresolved, only
  really works for trivial cases like a desktop with a single wired
  connection.
 
 Still your sample code would be nice to read for me. If you don't mind
 uploading it would be nice.
 
 Are you still interested in working on this? If yes let me know, then
 I'll try to keep something like a public todo list of my work fopr
 better coordination.

I'd definitely be interested - NetworkManager support is the only real
thing that keeps me tied to Gnome on my laptop!

I'm not much of a GUI developer, but I'll try to dig up the sample
client I was working on tonight.

-- 
Ross Vandegrift
[EMAIL PROTECTED]

The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell.
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel