- User Since
- Mar 25 2013, 3:23 AM (513 w, 4 d)
Feb 24 2022
Nov 23 2021
May 26 2020
May 25 2020
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.
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
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
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
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
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
Sep 13 2017
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
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