Here is another patch from the SUSE Security team that will help make things better again (sorry arc isn't setup here)

The umount has another possible attack surface. Even if the program only
allows removable devices to be mounted ... I could insert a removable device
with a UNIX file system on it that contains symlinks.

yeah from a Legal perspective I guess an overly complex way to get it is significantly different to not being able to get it :-)

Fixed in 0.24

In T8645#151412, @raster wrote:

going to flag this to try and reproduce once i pull out my laptop and plug it into monitors etc...

Apr 07 15:29:04 tek-top.simotek.local /usr/lib/gdm/gdm-x-session[2630]: RRR: do change because screen count changed

implies e was going to change the screen config but then decided to skip because:

Apr 07 15:29:04 tek-top.simotek.local /usr/lib/gdm/gdm-x-session[2630]: RRR: skip change with lid screens open and no ext

somewhere in between e skipped.. is this git master e?

gdm gives the world really nice logs so here you go something seems borked, it detects that it should be going from 3 -> 1 but never does. A keybinding to Update and re-apply screen setup is then fixing the issue.

In T8601#150535, @raster wrote:

that's because you have your screens backwards. the bindings change screen count by 1 or -1 ... screens are numbered based on which is primary or not (0) as well as the priority value in the screen setup - highest priority is sorted to start of screen count. if priority is the same then it's in order of x value .... then y value for screen location.... :)

It seems like .elementary/config/openSUSE-classic/base.cfg had the wrong theme installed so i'm going to try and wipe that directory openSUSE-classic is the name of the profile i'm using (openSUSE ships several other profiles)

Thanks

@netstar one for you?

Sorry half awake me didn't leave enough info, this issue has been triggered in the update from python3.6 to 3.7 on efl 1.20.0, (i'll try with 1.21 later not sure why that didn't get updated) according to the script i'm using the bundled c files.

In T7373#124370, @ProhtMeyhet wrote:

are you able to test, if you use an open source gpu driver (like radeon, noveau), if this happens with kernel 4.13? because since kernel 4.14 I've got some wacky problems.

for example, for me currently (4.18) sometimes on radeon there seems to be a race somewhere with 2x the same monitor type, whereas the kernel gets confused which one is connected to which connector...

I can confirm reverting 5cb6e1e8fafca16f27a3311c36a917cf88b4032d move config/ to data/config/ fixed the issue.

I also don't think the vote are necessary unless we get to a point where we can't come to a clear consensus while discussing an issue, at that point we can just open a yes/no vote on that one item, I think that would also be less confusing.

sorry the last few months have been pretty busy with work deadlines, i'll get back to this soon.

Apparently still no luck. I'll try amd get a raspberry pi + gdb out on my desk later.

@raster it doesn't look like enlightenment_ckpasswd is built on e22 with autotools builds, autotools is still the default / main supported build system in the e22 branch.

In T6779#112115, @raster wrote:

ok. found out why - you're missing libpam dev/devel pkgs. e's build auto-enables pam if found, otherwise disables.

note - i think the code change here is that without pam enabled auth ALWAYS FAILS. before i think it ALWAYS SUCCEEDED irrespective of passwd if u were missing pam support

so basically issue is a long standing one that pam is optional and auto-detected on linux. you can't use system passwords without pam support.

I can confirm 3c4e25360eb65d0bc9dbfbc2d697898d5b42280d is the issue, as a really hacky workaround you can ssh in from another machine if you have one and kill the enlightenment process.

I'm going to close this as won't fix, if we have any spec files left in git we should remove them, they are not maintained by anyone.

Haven't seen it but also haven't been using e to open jpgs, i'll try and replicate it again tonight

<_ami_> raster, https://github.com/torch/torch7/issues/1035
<raster> _ami_: and how to not use lightuserdata then?
<raster> also 47 bits is just not enough ... certainly not
<_ami_> raster, https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-260205661
<Simotek> raster maybe, but i'll have to set up a build environment on one of my rpi's
<raster> this seems to be a general issue that has no solution :(
<raster> it's probably now not an eoid but a real ptr
<raster> and on arm64 a real ptr is getting high bits set
<raster> which basically is malloc returns
<raster> and ... there isnt much we can do
<raster> well ok maybe its something internal to luajit doing it
<raster> like that thread says
<_ami_> lua_pushlightuserdata() is used in efl code.
<raster> yes
<_ami_> they suggest to use static variable for lua_pushlightuserdata
<raster> we need it to pass referneces to native stuff around
<_ami_> raster, https://github.com/LuaJIT/LuaJIT/pull/245/commits/aafb49ea89dba570b583103f8163ba8368669a48

• antoinef (~antoine@static-css-ccs-204145.business.bouyguestelecom.com) has joined
• Puppet_Master has quit (Ping timeout: 250 seconds)

<raster> they are doing non-portable things there to make it happen
<raster> the allocation and double-ref thing i mentioned earlier
<raster> with a custom allocator to ensure the addr uses only 47 bits (i assume lj_mem_newt does)
<raster> i mean edje does this, elua does it and the evas filters do it too
<_ami_> seems like they fixed in ljit 2.1?
<raster> no
<raster> Simotek is having the issues with 2.1
<_ami_> hmm
<raster> its even in luajit git master (the 47 bit check)
<raster> its just horrible to remove 17 bits of our pointers on 64bit
<raster> why it cant do what it does for 32bit... i don't know
<raster> thatrs an explicit choice
<raster> but i know i can limit our eoid's to 47 bits
<raster> but not generic pointers
<raster> https://github.com/LuaJIT/LuaJIT/commit/6538c8a18711a6eb009def36050acd5f02e42aec#diff-45038fcc57de87ff5df7249e144ba0dd
<raster> he says to use ffi+cdata
<raster> now we need q66
<raster> Simotek: need to bug q66
<Simotek> ok
<jpeg> oh sweet. there's a solution then :)
<raster> but we have lots of instances
<raster> src/lib/evas/filters/evas_filter_parser.c
<raster> src/lib/elua/elua.c
<raster> src/lib/edje/edje_lua2.c
<raster> src/lib/edje/edje_lua.c
<_ami_> yup, a lot.
<raster> lots of lua_pushlightuserdata
<jpeg> do we have anyone besides felipe who's well knowledgeable about c++ (and hopefully efl too)
<jpeg> nah evas filters don't matter. lightuserdata is not eo
<jpeg> evas filters don't require luajit
<raster> but if we build with luajit this will be a problem
<raster> the problem isnt now eoid
<raster> i can fix that
<raster> the problem is pointers with high values
<raster> stack values can have the high bits set on arm
<raster> thats a crux of things
<jpeg> hmm
<jpeg> right
<raster> lua_pushlightuserdata(L, (void *) &this_is_not_a_cat);
<raster> that isnt stack but in theory it could have high bits set
<raster> lua_pushlightuserdata(L, pgm);
<raster> that pgm is a stack val so on arm64 apparently it will have high bits set
<jpeg> yeah but you're missing the point: it's not a cat
<jpeg> j/k
<raster> ahahahha
<raster> but this is in various places
<raster> so i guess i could try and hack around and convert ptrs into id's in a table to keep values low
<jpeg> just poke q66 :)
<raster> q66: evil luajit stuff.... above ^^^^^^^^^^^^^66

• Puppet_Master (~Puppet_Ma@247-249-190-109.dsl.ovh.fr) has joined

<raster> well one way is to do an indirection for all lightuserdata + touserdata which gets it back

https://github.com/ImageMagick/ImageMagick/issues/861

gah how did this get added to the wrong project, seems like gtk doesn't like it either

Can you check to see if the package "enlightenment-theme-openSUSE" is installed, I suspect the dependency got removed at some point. I'll push through a maintenance update if thats the case

In T5976#98534, @wltjr wrote:

Is this supposed to be resolved in 0.22-alpha? If so its not for me on my dual display desktop under X.

In T5905#98405, @wltjr wrote:

I brought up GPG key signing on edevel list and it was not well received and knocked down. SSH is good enough. I digress, but that was the final call. If things change that would be great, I gpg sign every commit. I fully support gpg signing for releases if not commits, ideally both. Maybe others are open to gpg signing releases. But at that point could just go ahead and gpg sign commits.

I tried to get gpg signing to be done at the dev days gathering. I do not believe they did that. A gpg key without signatures and web of trust is pretty moot. Though we could likely get around this. Best to always verify in person, with hopefully legit ID/Passport. Though those are easily counterfeited.

Many projects do not do gpg signing. I am not sure I have come across many if any that gpg signed checksums. Mostly a way for others to vet against upstream. I am not sure there is as much concern over the checksum being changed on E severs. Thus gpg signing maybe hard to justify to others even for releases.

Yeah but for it to be really useful you also have to also sign that checksum with a gpg key and upload the signature as well. If you have those things you can teach build systems like openSUSE's to automatically verify that the package is valid and created by the right person.

Yep i'm trying to get the time, hopefully it will be soon.

Feel free to create these bugs on my themes github, https://github.com/simotek/Enlightenment-Themes its most likely my themes are missing fixes

@bmwiedemann i'm in the process of creating new efl updates this week, i'll backport the above patch as part of it as there won't be another feature release for 3 months

@zmike after 5-10 minutes of playing with your WIP branch it seems that the issue is not there.

Ok seen as I seem to be able to replicate it pretty easily i'll try again with each of those removed 1 by 1 and see what I end up with

In T5589#92388, @DaveMDS wrote:

Not that I see so much difference with doc strings disabled,
here the generated C files goes from 511628 lines to 508292

I don't know how to test the out-of-memory issue, but I bet this will not resolve it :(

(as a side note I can successfully build python-efl on a RaspberryPI3 with 760MB of ram and 2GB of swap)

Tumbleweed should have or should be getting a new rebuild of the default theme really soon, hopefully the others will follow over the weekend.

This seems to be a regression from 1.19

Yep, thats the same as the one i've seen, its hitting the process memory limit for i586/i686 our machines still had plenty more room available.

@raster the theme in question doesn't have any transparency so its not that, i'm going to try and update the theme to the efl 1.19 break but either way it seems to be a break in theme compatibility.

This was running on the software engine, the issue doesn't seem to exist on the hardware engine

I have efl 1.19 here which is pretty recent

In T5470#87668, @TwoD wrote:

In T5470#87663, @simotek wrote:

In T5470#87631, @ApB wrote:

On wayland you cant unlock E after it locks. Fun stuff ?

Well that sounds like a different bug that probably deserves its own ticket.

Maybe, but I have the same issue under X after updating to kernel 4.11 and EFL-git and E-git today.

In T5470#87631, @ApB wrote:

On wayland you cant unlock E after it locks. Fun stuff ?

Sure I was considering that but wasn't sure if we wanted it in upstream e, i'm traveling the next 2 weeks but i'll try and find time for it.

For some reason I didn't include a link to that patch https://bugzilla.suse.com/attachment.cgi?id=726016