Re: Libwayland update causes Plasma desktop freeze on login (email correction)

Sorry for the new email, and my English, but maybe I wasn't precise in the previous one, in 
referring to the compilation the reference was only to the packages and not to the users, the 
correct text is the following:

"As for 'system packages', unlike others _packages_, I prefer not to compile/install them from 
sources but to refer to the official releases, so for the proposed options I will opt for "not 
using backported wayland"

Sorry again for the email and Thanks again to everyone.

Enrico


Il 25/09/24 08:41, Enrico Rivarola ha scritto:
> Thanks for the reply Aurélien.
>
> As a normal debian user I use backports to be as updated as possible on packages (e.g. latest
> libreoffice released these days).
>
> As for 'system packages', unlike others, I prefer not to compile/install them from sources but
> to refer to the official releases, so for the proposed options I will opt for "not using
> backported wayland".
>
> Thanks again to everyone who responded to my request.
>
> Enrico
>
>
> Il 24/09/24 22:04, Aurélien COUDERC ha scritto:
>> Hi Enrico,
>>
>> Le 24 septembre 2024 09:50:54 GMT+02:00, Enrico Rivarola<[email protected]>   a écrit :
>>> I am aware that packages in 'debian backports' may 'lead to some incompatibility risks'
>> Yes.
>>
>>> but
>> Not sure whether "but" is appropriate. Maybe "thus" ?
>>
>>> from what I have been able to understand the problem seems to be due to other packages (it seems 'kwin') not aligned with the updated packages ( see bug 1076729 (1) and 1081941 (2) ).
>>>
>>> At the moment I am not able to try solutions such as rebuild KWin or other system packages, hence my request to the maintainers if it is possible to backport/update the packages in the bookworm-backports in order to have all aligned and working so that we can update the system from backports without building or pinning any packages.
>> As I explained in #1076729 the kwin-side fix is in extra-cmake-modules to pass the correct build flags while building kwin to ensure that it doesn’t leak private symbols into the global namespace.
>>
>> Upstream also mentioned in an IRC discussion that there was a potential way to prefer internal symbols in wayland which would work around kwin’s leak of private symbols, but I don’t think it materialized in wayland’s code.
>>
>> So options include :
>> - not using backported wayland,
>> - using Xorg,
>> - using testing/unstable,
>> - convincing someone to apply the extra-cmake-modules MR linked in #1076729 to bookworm’s version and rebuild kwin with it,
>> - convincing someone to backport extra-cmake-modules >= 6.5 to bookworm and rebuild kwin with it.
>>
>> I’m not doing any of this patching / backporting myself.
>>
>>
>>
>> Happy hacking,
>> --
>> Aurélien
>>
>>