Here is another patch from the SUSE Security team that will help make things better again (sorry arc isn't setup here)
Feb 24 2022
Nov 23 2021
May 26 2020
May 25 2020
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.
Apr 26 2020
yeah from a Legal perspective I guess an overly complex way to get it is significantly different to not being able to get it :-)
Apr 22 2020
Apr 19 2020
Fixed in 0.24
Apr 16 2020
Apr 7 2020
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: 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: RRR: skip change with lid screens open and no ext
somewhere in between e skipped.. is this git master e?
Apr 6 2020
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.
Apr 5 2020
Feb 5 2020
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.... :)
Feb 4 2020
Jan 23 2020
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)
Jan 14 2020
Apr 14 2019
Mar 22 2019
Feb 26 2019
@netstar one for you?
Feb 5 2019
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.
Sep 8 2018
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...
Aug 22 2018
I can confirm reverting 5cb6e1e8fafca16f27a3311c36a917cf88b4032d move config/ to data/config/ fixed the issue.
Aug 21 2018
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.
Aug 20 2018
Aug 16 2018
May 29 2018
May 1 2018
sorry the last few months have been pretty busy with work deadlines, i'll get back to this soon.
Apr 15 2018
Apparently still no luck. I'll try amd get a raspberry pi + gdb out on my desk later.
Mar 21 2018
@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.
Mar 20 2018
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.
Mar 19 2018
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.
Mar 14 2018
Mar 12 2018
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.
Mar 7 2018
Feb 12 2018
Haven't seen it but also haven't been using e to open jpgs, i'll try and replicate it again tonight
Nov 28 2017
Nov 23 2017
<_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.
<_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 (~firstname.lastname@example.org) 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> Simotek is having the issues with 2.1
<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> he says to use ffi+cdata
<raster> now we need q66
<raster> Simotek: need to bug q66
<jpeg> oh sweet. there's a solution then :)
<raster> but we have lots of instances
<_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
<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
<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
Nov 22 2017
Nov 12 2017
gah how did this get added to the wrong project, seems like gtk doesn't like it either
Nov 8 2017
Nov 6 2017
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
Sep 14 2017
Is this supposed to be resolved in 0.22-alpha? If so its not for me on my dual display desktop under X.
Sep 13 2017
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.
Sep 4 2017
Aug 22 2017
Yep i'm trying to get the time, hopefully it will be soon.
Aug 15 2017
Feel free to create these bugs on my themes github, https://github.com/simotek/Enlightenment-Themes its most likely my themes are missing fixes
Aug 7 2017
@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
Aug 2 2017
@zmike after 5-10 minutes of playing with your WIP branch it seems that the issue is not there.
Aug 1 2017
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
Jul 22 2017
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)
Jul 20 2017
Tumbleweed should have or should be getting a new rebuild of the default theme really soon, hopefully the others will follow over the weekend.
Jul 18 2017
This seems to be a regression from 1.19
Jul 17 2017
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.
Jul 13 2017
Jul 10 2017
@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.
Jun 26 2017
Jun 12 2017
This was running on the software engine, the issue doesn't seem to exist on the hardware engine
May 24 2017
I have efl 1.19 here which is pretty recent