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

In this case the wizard page isn't disabled, It is still there but if the wizard can detect the system keyboard layout it attempts to set it without showing the wizard page. See

The original Author has committed a follow up patch that should fix the issue (I'm in the process of confirming)

openSUSE tumbleweed now has kernel 4.11 and also hits the issue, we have some pretty responsive kernel devs so hopefully they can help although i'm traveling much of next week.

I didn't write whichever spec files are in the git repo so i'd expect them to be untested broken and out of date :-P

Seems to just be edje_cc, I think we have ways of handing timestamps etc if they exist. The enlightenment package is fine as it doesn't include .edj files, but every package with one is affected.

Well not really remembering, the Delete button should do the same as the menu, if thats move to trash then thats fine. Shift + Delete should really delete if normal delete is move to trash

Confirmed that patch fixes the issue, patch is also now backported.

git bisect seems to indicate this is a duplicate of T4389 c507f56110fd9b4442952c98f0e28b905aacf53a should fix it but i'll confirm after dinner

It seems that this issue is fixed in efl from git but not backported to 1.18.3

In T4940#77112, @raster wrote:

i suspect it's the driver filling n the alpha pixels on its own... :( try another driver...

It happens with both opengl and software rendering here

"elm_test->window states->alpha on" with the setting disabled will show the issue when running the default theme.

Heres the theme for good measure{F52365}

The 1.2 scaling was hard coded, thats now fixed for us which is good enough for now.

This may see some more changes as of today, ideally i'll also do similar for the keyboard layout dialog

Yep pretty much everything enlightenment and efl related is already built on obs mostly at https://build.opensuse.org/project/show/X11:Enlightenment:Factory and a couple of other associated repo's. I already have all the distro's that can be built from rpm .spec files being built and I try to keep them running.

@bu5hm4n given your commit hasn't been backported yet I guess it probably didn't break it, but i'll patch my e to see if it fixes it later

@jabol240 if i'm aware of a reasonable issue thats affecting users and has been fixed i'll try and get a point release out, the reality is though the stable branch especially for e is quite stable (maybe with the exception of wayland) so such issues don't come up often. For enlightenment atleast mike's current policy is waiting until just before a release to backport everything to the stable branch. The efl stable branch see's more traffic but its mostly either minor stuff or things that aren't affecting e users, again if something important is found and fixed i'll generally push the right people towards having another point release.

Ok so phab + ascii art doesn't work

In T4441#67807, @jabol240 wrote:

thanks :)

In T4441#67806, @raster wrote:

that's what we have as stable. use that.

Exactly! Stable branch! But from what I understand, this creates a burden for packagers, as they would have to edit the branch name in PKGBUILD after every big release, to maintain such a stable package. Then wouldn't it be simpler to create a branch with a fixed name "Stable" and sync it with the freshest of efl-1.18, efl-1.17, efl-1.16 with some script? That seems like zero-cost to me...