Seems this was fixed in the daily builds then.

OK, will close for now (but please come back if something reproducable is found...)

I was also thinking that maybe due to low memory conditions some process killer kicks in....

I can bake indirect even with the scans enabled [took quite a while though...]
System is a little sluggish while baking [thats normal, because GPU is hard at work], but seems to come back to normal after that...

If i disable the photoscanned objects from view / render ("HausVorne" / "HausVorne.mirrored") it looks like i can bake lights.
Maybe blender is having problems with these larger meshes... ?

have the file, will have a look [might take a bit...]

Sometimes i can recover by switching to a text console by CTRL-ALT-F3 and doing a "killall blender".

Here is the blend file (240MB....). Pls dont put on public shares...

Seems to occur with current blend file every time i bake indirect lightning.

• This issue does not occur every time. It is triggered by a user action which involves updating the evee viewport.
• When the crash occured, i have tried the same step again, sometimes that seems to work, sometimes the hang reappeared

Cannot reproduce here (970m, fedora29, gnome).

same result, closed unexpectedly.

Cannot reproduce here [fedora 29, 970m with 410.78 drivers].

@Salvatore De Paolis (iwkse) issues with PythonLibsUnix should be reported with details of why it fails exactly. See:

Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.

The texture generated in 2.7 is not smooth.
But this texture works the same way light is positioned.
First, almost half of the particles fly away.
Then the gradient part.
And, almost half of the remaining particles.

English is not my language, apparently the translator spoils the sense.
I tried to.

For updating software OpenGL to support Blender 2.8, there is T56315: Blender 2.8 with software GL does not start.

Yes, you can select other objects while being in editmode.
This can be useful (e.g. when setting a hook for selected vertices to another object), so not really a bug here...

Blender 2.8 uses Filmic color management by default, which has this effect. It looks odd but it's a result of how scene linear colors are not linear display space colors.

Also cannot really tell what is supposed to go wrong from the report.

The same situation in WIN7

Excuse me.
Don't catch the logic.
In edge selection mode, R click D works correctly.
You have to get used to it and be careful.
Checked with WIN7.

Duplicate of T59910

I can't observe any strange behaviour on Win 10 in 0661bcba3210.

Sorry this has been lying around for so long.
glibc 2.24 is recommended, but there are apparently workarounds, see T59489, T56837

Fixed rBf13a4b2f123d73bc382bf30f38348f90bc456879

I think you are using software rendering (so you are not using you GPU to render).
The vendor string and renderer string implies as much. And that is why you are locked to opengl 2.1.

lshw -c video shows my system is using i915.

$ glxinfo | grep -i opengl

OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 2.1 Mesa 8.0.5
OpenGL shading language version string: 1.20
OpenGL extensions: