This was fixed yesterday, please try a new build

This path resolution seems to fail if a PointerProperty with a PropertyGroup is defined on anything else than a real ID.

This comment here (from rBc6e3a20ab60b):

Confirmed, for me this already hangs in node_clipboard_copy_exec
(probably endless loop because new node is automatically selected....)

Can confirm, there are a couple of these, will have a look...

Yes, Redo HUD is per Editor in 2.8 [wont show for Properties Editor]
I think the convention for 2.8 is more like "put your operators in the 3D view menus"...

This looks like expected behavior for me [2.79 was doing exactly the same].

@Sergey Sharybin (sergey): file was there in the report (made this more visible now...)

Looks like this is caused by adding a vanilla "Viewport" viewlayer and making it the first in the list
(special case in do_version_layers_to_collections() if there are layer overrides...)

Looks like this is caused by adding a vanilla "Viewport" viewlayer and making it the first in the list here
(special case in do_version_layers_to_collections() if there are layer overrides...)

/* Make it first in the list. */
BLI_remlink(&scene->view_layers, view_layer);
BLI_addhead(&scene->view_layers, view_layer);

Confirmed, checking...

In T59062#604282, @Philipp Oeser (lichtwerk) wrote:

So making a single material user from the row.template_ID(ob, "active_material", new="material.new") doesnt seem to do the same thing as Object > Relations > Make Single User > Materials

caused by rB2778ecb58cd2 [which will cause the drag to not execute a button with the same icon and state]

Can confirm, bisecting...

So, I think we have all cases covered/answered, and to me it seems none of them are actually bugs.

I would have expected an alt-D option to make a linked duplicate, but there is no alt-D option in the Armature menu.

It is there (in object mode): Object > Duplicate linked

Not sure I understand correctly:

@Campbell Barton (campbellbarton) : is this OK to stay on your desk?

Was just an idea to avoid cyclic dependencies when picking curve bevobj/taperobj: P912
(but I guess a bad one because it doesnt cover everything...)

@Ron Zandbergen (Taaske) : I think thats fine... (no need for the 2.79 file)

AddressSanitizer: heap-use-after-free P911

Can reproduce here

This should also be fixed by rB57f0b175d7c9
(was crashing in ED_screen_user_menus_find because of no SpaceLink in between editors...)

@gsr b3d (gsrb3d) : please excuse the delay on this [just slipped under the radar...]
But was reported again T61487 and fixed rB57f0b175d7c9

@Rainer Trummer (aliasguru) : will wait for @Brecht Van Lommel (brecht) to decide if swapping 'BLENDER_RENDER' with 'CYCLES' is desired at this point (external) addons would probably require updates then...

Confirmed, checking...

This was already changed for spheres T57718 [in a way it is the other way around there -- was changed from size to radius]

@Rainer Trummer (aliasguru): cycles usually takes panels with BLENDER_RENDER as a compat engine into account, except for a few instances [like apertue as you mentioned]
check get_panels() in cycles addon to see which panels cycles excludes...

Confirmed, checking...

was comitted rB2424bb3d5ef38702bb738431ab05bd4575374e96

This is what I thought T58438 was about... [not sure what that fix in that report actually did...]

thanx @Bastien Montagne (mont29) for clearing that up! (sorry for my uneducated fiddeling here...)

I can only repeat myself: I am on shaky ground here, if the above file doesnt work for you, I am probably out of ideas...

Not sure if this is the recommended way, but picking a region type for your spacetype that doesnt draw panels automatically seems fine, I guess...
So for space TEXT_EDITOR, you could use bl_region_type = 'HEADER', bl_region_type = 'WINDOW'?

This has always been the case [checked previous versions as well].
Anyways, since the original author is not active anymore (see @Paul Kotelevets (1D_Inc) comment in rBA08d30a13bf6a), will have to look at that sometime...

Confirmed, checking (caused by rB9ec944bbab7a)...

Can confirm the crash (when accessing/printing the current_item after the recursive call)

I have reassigned T60623 and T59352 to @Sergey Sharybin (sergey) now (since I am not sure how to solve this in the desired way [using depsgraph alone]...)

Since D4309 doesnt seem to be the desired solution, I'll step down from this and put on @Sergey Sharybin (sergey) 's desk, sorry...

Since D4309 doesnt seem to be the desired solution, I'll step down from this and put on @Sergey Sharybin (sergey) 's desk, sorry...

Oki, closing then

Confirmed, checking...

Menus are a bit limited in regards to layout.
I dont have an exact list of these limitations (I just remeber I had an issue in D4215 as well).

With multiple outliners open Blender still knows (it seems) which collection entry was last clicked; the text gets brighter white in all collection windows.

@Thomas Androxman (ThomasAn) : Sorry, my bad, yes the selection seems to sync across multiple outliners...
However: not sure if is good practice to rely on the outliners selection from the 3DView? (you could also have no outliner open at all....)

I think @Clément Foucault (fclem) needs to chime in here...
@Gabriel Moro (gabrielmoro) But as a preparation: could you start blender with the --debug-gpu-force-workarounds and paste the output as a .txt file here? (maybe this can give a hint...)

BLI_assert failed: /blender/blenkernel/intern/DerivedMesh.c:2181, mesh_get_eval_final(), at 'DEG_debug_is_evaluating(depsgraph) == 0'

@Bastien Montagne (mont29): do you know about this addon?

Which windows version is this?
@LazyDodo (LazyDodo) : ever heard of this?

This addon is not maintained by blender, please contact the original author instead...

That indeed looks wrong to me, @Clément Foucault (fclem): mind having a look?

could be related to T59827?

was fixed in rBS23c14a0bbacf2b7f904905ec94e2d9b1be67f45e