[E-devel] emotion: vlc, xine not looking good
so in the name of some simplification... our vlc support just doesn't work (libvlc or generic player that's vlc based). xine still kind of works - but seems to have bugs. i won't detail them here. try and see. my point is more... perhaps time to simplify and remove: 1. xine, libvlc and generic players for emotion. 2. remove the build options for the above 3. simplify to a -Dgstreamer=true/false that enables the only emotion module left AND the evas gstreamer loader (and remove it from the evas image loaders as there are now 2 gst dependency options)... less code to test, debug and maintain, fewer options to confuse people. the code removed is broken now anyway, so we don't lose functionality. comments? -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FlatPak runtime
On Mon, 2 Mar 2020 15:52:58 -0300 Vinícius dos Santos Oliveira said: > Em seg., 2 de mar. de 2020 às 13:35, Carsten Haitzler > escreveu: > > > you're going to find an afl runtime flatpak is going to have a lot of > > system > > lib deps... you will have to solve systemd support too :) > > > > Thanks for the answer. > > now e will have some problems for you too. acpid needs to be run by root on > > the host... you might find you have to ship lots of xlibs and wayland libs > > in > > the efl runtime... > > > > It's not a good idea to package any shell (be it a terminal shell like ZSH > or a graphical shell like E) to run on a sandbox. It doesn't make sense as > the shell will no longer let you explore your system but a sandboxed system > (so it doesn't perform a shell's job). SELinux or alike policies work > better on such programs. sure. you just will have to ensure e has no sandboxing at all. efl will have lots of deps and it's going to be a challenge to have a flatpak runtime that works on systemd vs non-systemd systems. e really mostly just needs efl plus libc/libm//liblibpthread the usual and libpam. if you build e with wl support it will also use libuuid from util-linux, libwqayland* libs and libxkbcommon too. as i said - at runtime e will want acpid running as root on most pc-like systems (not on things like rpi arm systems though will want it on bigger arm systems that are pc-like with acpi/uefi etc.). ppc systems also will likely want acpd running. also eeze in efl (that e uses) will probably want udisks running (possibly not in future as i have, in git, a new mounting replacement for e) an optional dep for e now also is libddcutil (provided by the ddcutil project) - runtime detected via dlopen. it'll have to be in /etc/ld.so.conf search paths and not LD_LIBRARY_PATH because it's used by a setuid root util for monitor backlight controls. it'll do more in future too like control color correction on the monitor and read monitor rotation sensors etc. it's actually essentially all there other than the whitelist of ddc cmds only allows backlight swizzling right now. i can whiteliest more over time as support in e's ui turns up. e has it's sysactions.conf file also customized per distro - it's an integration point to limit access to privileged features based on user and group membership. the power bits (shutdown/reboot/suspend ec.) are unused on systemd/logind systems as e will talk to it via dbus for these, but other things like the mounting, l2ping, rfkill etc. are necessary and may need customizing as the user/group membership may need. there is a new system.conf too in the same dir for the new setuid super-tool replacement. e will need rfkill installed for bt/bluez support to work right (and that's another system daemon/service needed - via dbus, but rfkill is needed to get some bt systems to work as they start rfkilled and asking bluez to power them on doesnt unblock the rfkill). e will need connman running for network control/support (also like bluez - running as root). there's pulseaudio for audio support as well. e can talk to alsa directly too though i never test that... that's what i can think of as a quick guide to dependencies and gotchas... > I only intend to create the runtime for apps based on EFL. But it's a good > idea to check what other libraries besides EFL E depends on. Maybe I should > put them as part of runtime if it looks like lots of apps will need them or > there is some reason for them to be updated behind the app's back (like > openssl and any crypto lib). > > > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FlatPak runtime
Em seg., 2 de mar. de 2020 às 13:45, Boris Faure escreveu: > I wanted to look into it to be able to package Terminology. Here is a > file of what I did to package Terminology as a snap: > https://github.com/billiob/terminology/blob/master/snap/snapcraft.yaml > It's not a good idea to package Terminology as FlatPak (even if you can do that). But the list of dependencies you gathered on this file is going to help me tons. Thank you for the list and for the hand. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FlatPak runtime
Em seg., 2 de mar. de 2020 às 13:35, Carsten Haitzler escreveu: > you're going to find an afl runtime flatpak is going to have a lot of > system > lib deps... you will have to solve systemd support too :) > Thanks for the answer. now e will have some problems for you too. acpid needs to be run by root on > the host... you might find you have to ship lots of xlibs and wayland libs > in > the efl runtime... > It's not a good idea to package any shell (be it a terminal shell like ZSH or a graphical shell like E) to run on a sandbox. It doesn't make sense as the shell will no longer let you explore your system but a sandboxed system (so it doesn't perform a shell's job). SELinux or alike policies work better on such programs. I only intend to create the runtime for apps based on EFL. But it's a good idea to check what other libraries besides EFL E depends on. Maybe I should put them as part of runtime if it looks like lots of apps will need them or there is some reason for them to be updated behind the app's back (like openssl and any crypto lib). -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FlatPak runtime
On 20-03-02 16:35, Carsten Haitzler wrote: > On Mon, 2 Mar 2020 11:53:43 -0300 Vinícius dos Santos Oliveira > said: > > > Em seg., 2 de mar. de 2020 às 07:15, Carsten Haitzler > > escreveu: > > > > > On Sun, 1 Mar 2020 20:14:33 -0300 Vinícius dos Santos Oliveira > > > said: > > > > > > > What are E devs' thoughts on an E's runtime for FlatPak? > > > > > > are you volunteering? > > > > > > > Yes, but I need to know what are other essential libs besides EFL and its > > dependencies to make an “EFL SDK” and I'd like to know what you guys think > > on the topic. > > you're going to find an afl runtime flatpak is going to have a lot of system > lib deps... you will have to solve systemd support too :) > > now e will have some problems for you too. acpid needs to be run by root on > the host... you might find you have to ship lots of xlibs and wayland libs in > the efl runtime... > > e uses ptrace and contains setuid root utils to ensure it runs. sandboxing is > going to be a problem. e will not work well sandboxed as it kind of expects to > get a lot of access to /sys, /dev, /proc, and to the entire fs due to efm, and > more. it'll want to bind to a few dbus services too so sanboxing dbus will be > bad(tm). e has to fork and exec apps and more :) Thanks for doing this. I wanted to look into it to be able to package Terminology. Here is a file of what I did to package Terminology as a snap: https://github.com/billiob/terminology/blob/master/snap/snapcraft.yaml The main issues I have so fare are related to launching ethumd and efreetd. It hope it'll help you. -- Boris Faure Pointer Arithmetician 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] FlatPak runtime
On Mon, 2 Mar 2020 11:53:43 -0300 Vinícius dos Santos Oliveira said: > Em seg., 2 de mar. de 2020 às 07:15, Carsten Haitzler > escreveu: > > > On Sun, 1 Mar 2020 20:14:33 -0300 Vinícius dos Santos Oliveira > > said: > > > > > What are E devs' thoughts on an E's runtime for FlatPak? > > > > are you volunteering? > > > > Yes, but I need to know what are other essential libs besides EFL and its > dependencies to make an “EFL SDK” and I'd like to know what you guys think > on the topic. you're going to find an afl runtime flatpak is going to have a lot of system lib deps... you will have to solve systemd support too :) now e will have some problems for you too. acpid needs to be run by root on the host... you might find you have to ship lots of xlibs and wayland libs in the efl runtime... e uses ptrace and contains setuid root utils to ensure it runs. sandboxing is going to be a problem. e will not work well sandboxed as it kind of expects to get a lot of access to /sys, /dev, /proc, and to the entire fs due to efm, and more. it'll want to bind to a few dbus services too so sanboxing dbus will be bad(tm). e has to fork and exec apps and more :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: elm_label: sizing eval is called _on_label_resize to ensure label size.
Hello.
I reverted this change as it broke the test suite for elementary on my
system as well as on CI. Please have a look at this again.
regards
Stefan Schmidt
On 02.03.20 08:53, Bowon Ryu wrote:
hermet pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=3d57fc0c92d10337c441ec830361751de510e9b1
commit 3d57fc0c92d10337c441ec830361751de510e9b1
Author: Bowon Ryu
Date: Mon Mar 2 16:53:10 2020 +0900
elm_label: sizing eval is called _on_label_resize to ensure label size.
Summary:
EFL should guarantee size of label in various situations that the label is
resized.
elm_layout_sizing_eval called on on_label_resize.
Test Plan: N/A
Reviewers: YOhoho, zmike, Hermet
Reviewed By: Hermet
Subscribers: cedric, #reviewers, Hermet, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11435
---
src/lib/elementary/elm_label.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/elementary/elm_label.c b/src/lib/elementary/elm_label.c
index 2279955f01..4f19e36e32 100644
--- a/src/lib/elementary/elm_label.c
+++ b/src/lib/elementary/elm_label.c
@@ -247,8 +247,8 @@ _on_label_resize(void *data, Evas *e EINA_UNUSED,
Evas_Object *obj EINA_UNUSED,
{
ELM_LABEL_DATA_GET(data, sd);
+ elm_layout_sizing_eval(data);
if (sd->slide_mode != ELM_LABEL_SLIDE_MODE_NONE) _label_slide_change(data);
- if (sd->linewrap) elm_layout_sizing_eval(data);
}
static int
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FlatPak runtime
Em seg., 2 de mar. de 2020 às 07:15, Carsten Haitzler escreveu: > On Sun, 1 Mar 2020 20:14:33 -0300 Vinícius dos Santos Oliveira > said: > > > What are E devs' thoughts on an E's runtime for FlatPak? > > are you volunteering? > Yes, but I need to know what are other essential libs besides EFL and its dependencies to make an “EFL SDK” and I'd like to know what you guys think on the topic. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FlatPak runtime
On Sun, 1 Mar 2020 20:14:33 -0300 Vinícius dos Santos Oliveira said: > What are E devs' thoughts on an E's runtime for FlatPak? are you volunteering? > -- > Vinícius dos Santos Oliveira > https://vinipsmaker.github.io/ > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
