Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-05-10 Thread Carlos Henrique Lima Melara
Hi, Dylan!

On Fri, Apr 05, 2024 at 09:28:02PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> > Meanwhile, I pinged upstream to ask for their opinion about
> > that to make sure we are not going to break stuff.
> 
> launcher-libseat has an higher priority than launcher-logind,
> that means enabling launcher-libseat will change the default
> behavior for all users. Although this should be harmless
> because libseat should contact logind, it doesn't work for
> whatever reason. I just tested with a VM without a
> graphical login. I can launch weston 10.0.1-1, but
> it fails with 10.0.1-1+deb12u1. So, I guess it would
> require more changes unsuitable for bookworm :-(

First of all, thanks for being so helpful in this wishlist bug!

I did some investigation on weston and turns out out it's pretty easy to
change the launcher order weston uses (see attached patch). I tested it
with a debian12 vm and weston comes up correctly using systemd-logind.
As you said, without this patch, it doesn't. I also did the ABI
compatibility analysis and it's 100% compatible with bookworm's weston.

I think it's a harmless patch, but it would be nice if you could ping
upstream about it. Also, now we have a patch and a new feature so maybe
you think it's too much for a stable update.

Is there a formal procedure to enter Debian's X strike force? Do you
usually use a mailing list or maybe irc? Is there a wiki with more
documentation? I'm spending quite some time looking at it's package so I
might as well try to contribute :-)

> 
> Best,
> Dylan

Cheers,
Charles
From 8d77f72ef669db60a11c9e5e2dd491a638ba76f8 Mon Sep 17 00:00:00 2001
From: Carlos Henrique Lima Melara 
Date: Thu, 9 May 2024 12:53:47 -0300
Subject: [PATCH] d/p/move-libseat-launch-to-lowest-priority.patch: add new
 patch

---
 ...ve-libseat-launch-to-lowest-priority.patch | 39 +++
 debian/patches/series |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 debian/patches/move-libseat-launch-to-lowest-priority.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/move-libseat-launch-to-lowest-priority.patch b/debian/patches/move-libseat-launch-to-lowest-priority.patch
new file mode 100644
index ..e13d090e
--- /dev/null
+++ b/debian/patches/move-libseat-launch-to-lowest-priority.patch
@@ -0,0 +1,39 @@
+From: Carlos Henrique Lima Melara 
+Date: Thu, 9 May 2024 12:46:45 -0300
+Subject: libweston/launcher-util: move launcher-libseat to lowest priority
+
+Previously we had launcher-libseat support disabled in bookworm as it was the
+default in upstream weston. To enable it and support other init systems not
+relying on systemd-logind, we move it to lowest priority. In this way, we can
+have the same behaviour as previously for systems with systemd, but also support
+systems using libseat for example.
+
+Fowarded: not-needed
+Bug-Debian: https://bugs.debian.org/1066112
+Last-Update: 2024-05-09
+---
+ libweston/launcher-util.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/libweston/launcher-util.c b/libweston/launcher-util.c
+index b2219b6..24e74cb 100644
+--- a/libweston/launcher-util.c
 b/libweston/launcher-util.c
+@@ -37,14 +37,14 @@
+ #include 
+
+ static const struct launcher_interface *ifaces[] = {
+-#ifdef HAVE_LIBSEAT
+-	_libseat_iface,
+-#endif
+ #ifdef HAVE_SYSTEMD_LOGIN
+ 	_logind_iface,
+ #endif
+ 	_weston_launch_iface,
+ 	_direct_iface,
++#ifdef HAVE_LIBSEAT
++	_libseat_iface,
++#endif
+ 	NULL,
+ };
+
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..cf9b9c2b
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+move-libseat-launch-to-lowest-priority.patch
-- 
2.43.0



signature.asc
Description: PGP signature


Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-04-05 Thread Carlos Henrique Lima Melara
Hi,

On Fri, Apr 05, 2024 at 09:28:02PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> > Meanwhile, I pinged upstream to ask for their opinion about
> > that to make sure we are not going to break stuff.
> 
> launcher-libseat has an higher priority than launcher-logind,
> that means enabling launcher-libseat will change the default
> behavior for all users. Although this should be harmless
> because libseat should contact logind, it doesn't work for
> whatever reason. I just tested with a VM without a
> graphical login. I can launch weston 10.0.1-1, but
> it fails with 10.0.1-1+deb12u1. So, I guess it would
> require more changes unsuitable for bookworm :-(

That's unfortunate! Is it ok for you if I poke around next week to
try to understand the problem? If there isn't a solution that keeps it
completely compatible for bookworm users, we can close this bug.

> Best,
> Dylan

Cheers,
Charles


signature.asc
Description: PGP signature


Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-04-05 Thread Dylan Aïssi
Hi,

Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> Meanwhile, I pinged upstream to ask for their opinion about
> that to make sure we are not going to break stuff.

launcher-libseat has an higher priority than launcher-logind,
that means enabling launcher-libseat will change the default
behavior for all users. Although this should be harmless
because libseat should contact logind, it doesn't work for
whatever reason. I just tested with a VM without a
graphical login. I can launch weston 10.0.1-1, but
it fails with 10.0.1-1+deb12u1. So, I guess it would
require more changes unsuitable for bookworm :-(

Best,
Dylan



Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-04-05 Thread Dylan Aïssi
Hi Charles,

Sorry for not answering before.

Le jeu. 4 avr. 2024 à 16:04, Carlos Henrique Lima Melara
 a écrit :
>
> > So, I have good and bad news, but I guess they are mostly good.
> >
> > THe bad news first, when I was checking the upstream commits, I saw some
> > changes in libweston.h which raised some flags about ABI incompatibilty
> > because they introduced some members in a publicly exposed struct. So I
> > set my feet on testing abi changes with abi-dumper +
> > abi-compliance-checker (it was my first time, that's why it took so
> > long).
> >
> > The actually bad new is 08979a1 (from 10.0.4) [1] makes some problematic
> > changes in libweston.h:
> >
> > --- a/include/libweston/libweston.h
> > +++ b/include/libweston/libweston.h
> > @@ -1289,6 +1289,7 @@ struct weston_view {
> > struct weston_surface *surface;
> > struct wl_list surface_link;
> > struct wl_signal destroy_signal;
> > +   struct wl_signal unmap_signal;
> >
> > /* struct weston_paint_node::view_link */
> > struct wl_list paint_node_list;
> > @@ -1441,6 +1442,7 @@ struct weston_pointer_constraint {
> > bool hint_is_pending;
> >
> > struct wl_listener pointer_destroy_listener;
> > +   struct wl_listener view_unmap_listener;
> > struct wl_listener surface_commit_listener;
> > struct wl_listener surface_activate_listener;
> >  };
> >
> > This introduces an ABI incompatibility in libweston as caught by
> > abi-compliance-checker (report attached):
> >
> > Comparing ABIs ...¬
> > Comparing APIs ...¬
> > Creating compatibility report ...¬
> > Binary compatibility: 77.8%¬
> > Source compatibility: 100%¬
> > Total binary compatibility problems: 1, warnings: 1¬
> > Total source compatibility problems: 0, warnings: 1¬
> > Report: compat_reports/libweston-10.so.dump/0_to_1/compat_report.html¬
> >
> > I think this would get a solid NO from the release team (although I'm
> > not sure). Since the whole 10.0.4 release (the 4 commits) are related to
> > each other, I think we won't be able to pick it.
> >
> > That said, I started testing with the 10.0.3 release (because if we
> > can't get the latest, let's try to get something at least). And the
> > results are good, we have 100% abi and api compatibility for all DSOs,
> > even internal ones.
> >
> > Also, building the 10.0.3 (always with libseat launcher support
> > enabled), the build time tests give the same results (with 10.0.5 I was
> > getting slightly different results).
> >
> > I also tested the libseat launcher and normal launcher and they both
> > work.
> >
> > Finally, since the 10.0.5 patch release is only 1 commit, we can grab it
> > as a patch in the packaging side, so we would just miss the 10.0.4 patch
> > release.
> >
> > Well, it was a long email, but the main takeway is 10.0.4 introduces an
> > ABI incompatibility and would be unsuitable for a proposed-update to
> > bookworm. But we can use the 10.0.3 release plus the only commit in
> > 10.0.5 with libseat launcher support with 100% abi and api
> > compatibility.

Thanks a lot for your analysis and testing.

This ABI incompatibility it's unfortunate :-( In this case, I would
instead focus our request to your initial request, i.e. only enabling
the support of libseat without trying to push a new version. It would
make our request simpler and I hope easier to accept.
Initially, the next release point for Bookworm was planned tomorrow,
but due to the xz issue, it's postponed to a later date. I guess we are
too late for it anyway.

I pushed a new branch "debian-bookworm-updates" with only
10.0.1-1+deb12u1, could you please test this one, especially
with logind to make sure we are not introducing any regressions?
Meanwhile, I pinged upstream to ask for their opinion about
that to make sure we are not going to break stuff. I also
drafted a bug report for release team.

> Would you be okay of using 10.0.3 instead of 10.0.5?
>
> Also, if you need any help, please let me know.
>
> Maybe a disclaimer I should have sent in the first email, I do work at
> Toradex which is an embedded systems company and we are rebuilding
> weston with libseat-launcher support for a while. I'm also a Debian
> contributor and maintainer (DM) and I suggested to our management to try
> to send this change to Debian as a contribution. They were very
> supportive about contributing back to Debian, so here we are :-)

That is nice! Thank you for pushing your changes upstream :-)
Let's try to make it a success for more contributions.

Best,
Dylan



Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-04-04 Thread Carlos Henrique Lima Melara
Hi, Dylan.

Sorry to bother again, but I'd like to know the status of this upload.

On Sat, Mar 16, 2024 at 04:42:20PM -0300, Carlos Henrique Lima Melara wrote:
> On Wed, Mar 13, 2024 at 05:42:29PM +0100, Dylan Aïssi wrote:
> > Le mer. 13 mars 2024 à 16:05, Carlos Henrique Lima Melara
> >  a écrit :
> > >
> > > > I can try this week to prepare an updated package in a dedicated branch
> > > > in salsa, so you can test it. Then, if everything is okay, we could fill
> > > > the request to the release team.
> > >
> > > Sure, just let me know if you need help with anything and/or when the
> > > packaging is ready for testing.
> > 
> > Ready for testing at:
> > https://salsa.debian.org/xorg-team/wayland/weston/-/tree/debian-10.0
> > I just realized the branch name is confusing...
> 
> So, I have good and bad news, but I guess they are mostly good.
> 
> THe bad news first, when I was checking the upstream commits, I saw some
> changes in libweston.h which raised some flags about ABI incompatibilty
> because they introduced some members in a publicly exposed struct. So I
> set my feet on testing abi changes with abi-dumper +
> abi-compliance-checker (it was my first time, that's why it took so
> long).
> 
> The actually bad new is 08979a1 (from 10.0.4) [1] makes some problematic
> changes in libweston.h:
> 
> --- a/include/libweston/libweston.h
> +++ b/include/libweston/libweston.h
> @@ -1289,6 +1289,7 @@ struct weston_view {
> struct weston_surface *surface;
> struct wl_list surface_link;
> struct wl_signal destroy_signal;
> +   struct wl_signal unmap_signal;
> 
> /* struct weston_paint_node::view_link */
> struct wl_list paint_node_list;
> @@ -1441,6 +1442,7 @@ struct weston_pointer_constraint {
> bool hint_is_pending;
> 
> struct wl_listener pointer_destroy_listener;
> +   struct wl_listener view_unmap_listener;
> struct wl_listener surface_commit_listener;
> struct wl_listener surface_activate_listener;
>  };
> 
> This introduces an ABI incompatibility in libweston as caught by
> abi-compliance-checker (report attached):
> 
> Comparing ABIs ...¬
> Comparing APIs ...¬
> Creating compatibility report ...¬
> Binary compatibility: 77.8%¬
> Source compatibility: 100%¬
> Total binary compatibility problems: 1, warnings: 1¬
> Total source compatibility problems: 0, warnings: 1¬
> Report: compat_reports/libweston-10.so.dump/0_to_1/compat_report.html¬
> 
> I think this would get a solid NO from the release team (although I'm
> not sure). Since the whole 10.0.4 release (the 4 commits) are related to
> each other, I think we won't be able to pick it.
> 
> That said, I started testing with the 10.0.3 release (because if we
> can't get the latest, let's try to get something at least). And the
> results are good, we have 100% abi and api compatibility for all DSOs,
> even internal ones.
> 
> Also, building the 10.0.3 (always with libseat launcher support
> enabled), the build time tests give the same results (with 10.0.5 I was
> getting slightly different results).
> 
> I also tested the libseat launcher and normal launcher and they both
> work.
> 
> Finally, since the 10.0.5 patch release is only 1 commit, we can grab it
> as a patch in the packaging side, so we would just miss the 10.0.4 patch
> release.
> 
> Well, it was a long email, but the main takeway is 10.0.4 introduces an
> ABI incompatibility and would be unsuitable for a proposed-update to
> bookworm. But we can use the 10.0.3 release plus the only commit in
> 10.0.5 with libseat launcher support with 100% abi and api
> compatibility.

Would you be okay of using 10.0.3 instead of 10.0.5?

Also, if you need any help, please let me know.

Maybe a disclaimer I should have sent in the first email, I do work at
Toradex which is an embedded systems company and we are rebuilding
weston with libseat-launcher support for a while. I'm also a Debian
contributor and maintainer (DM) and I suggested to our management to try
to send this change to Debian as a contribution. They were very
supportive about contributing back to Debian, so here we are :-)

Cheers,
Charles






signature.asc
Description: PGP signature


Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-03-16 Thread Carlos Henrique Lima Melara
Hi, sorry for taking so long.

On Wed, Mar 13, 2024 at 05:42:29PM +0100, Dylan Aïssi wrote:
> Hi,
> 
> Le mer. 13 mars 2024 à 16:05, Carlos Henrique Lima Melara
>  a écrit :
> >
> > > I can try this week to prepare an updated package in a dedicated branch
> > > in salsa, so you can test it. Then, if everything is okay, we could fill
> > > the request to the release team.
> >
> > Sure, just let me know if you need help with anything and/or when the
> > packaging is ready for testing.
> 
> Ready for testing at:
> https://salsa.debian.org/xorg-team/wayland/weston/-/tree/debian-10.0
> I just realized the branch name is confusing...

So, I have good and bad news, but I guess they are mostly good.

THe bad news first, when I was checking the upstream commits, I saw some
changes in libweston.h which raised some flags about ABI incompatibilty
because they introduced some members in a publicly exposed struct. So I
set my feet on testing abi changes with abi-dumper +
abi-compliance-checker (it was my first time, that's why it took so
long).

The actually bad new is 08979a1 (from 10.0.4) [1] makes some problematic
changes in libweston.h:

--- a/include/libweston/libweston.h
+++ b/include/libweston/libweston.h
@@ -1289,6 +1289,7 @@ struct weston_view {
struct weston_surface *surface;
struct wl_list surface_link;
struct wl_signal destroy_signal;
+   struct wl_signal unmap_signal;

/* struct weston_paint_node::view_link */
struct wl_list paint_node_list;
@@ -1441,6 +1442,7 @@ struct weston_pointer_constraint {
bool hint_is_pending;

struct wl_listener pointer_destroy_listener;
+   struct wl_listener view_unmap_listener;
struct wl_listener surface_commit_listener;
struct wl_listener surface_activate_listener;
 };

This introduces an ABI incompatibility in libweston as caught by
abi-compliance-checker (report attached):

Comparing ABIs ...¬
Comparing APIs ...¬
Creating compatibility report ...¬
Binary compatibility: 77.8%¬
Source compatibility: 100%¬
Total binary compatibility problems: 1, warnings: 1¬
Total source compatibility problems: 0, warnings: 1¬
Report: compat_reports/libweston-10.so.dump/0_to_1/compat_report.html¬

I think this would get a solid NO from the release team (although I'm
not sure). Since the whole 10.0.4 release (the 4 commits) are related to
each other, I think we won't be able to pick it.

That said, I started testing with the 10.0.3 release (because if we
can't get the latest, let's try to get something at least). And the
results are good, we have 100% abi and api compatibility for all DSOs,
even internal ones.

Also, building the 10.0.3 (always with libseat launcher support
enabled), the build time tests give the same results (with 10.0.5 I was
getting slightly different results).

I also tested the libseat launcher and normal launcher and they both
work.

Finally, since the 10.0.5 patch release is only 1 commit, we can grab it
as a patch in the packaging side, so we would just miss the 10.0.4 patch
release.

Well, it was a long email, but the main takeway is 10.0.4 introduces an
ABI incompatibility and would be unsuitable for a proposed-update to
bookworm. But we can use the 10.0.3 release plus the only commit in
10.0.5 with libseat launcher support with 100% abi and api
compatibility.

What do you think?

> Best,
> Dylan

Cheers,
Charles
Title: libweston-10.so.dump: 0 to 1 compatibility report





API compatibility report for the libweston-10.so object between 0 and 1 versions on x86_64



BinaryCompatibility
SourceCompatibility

Test Info

Module Namelibweston-10.so.dump
Version #10
Version #21
Archx86_64
GCC Version12.2.0
SubjectBinary Compatibility

Test Results
Total Header Files26
Total Source Files27
Total Objects1
Total Symbols / Types352 / 259
Compatibility
77.8%


Problem Summary
SeverityCountAdded Symbols-0
Removed SymbolsHigh0
Problems withData TypesHigh0
Medium1
Low1
Problems withSymbolsHigh0
Medium0
Low0
Problems withConstantsLow0



Problems with Data Types, Medium Severity  1 
libweston.h

[+] struct weston_view  1 




Change
Effect
1
Field unmap_signal has been added at the middle position of this structural type.
1) Size of the inclusive type has been changed.2) Layout of structure fields has been changed and therefore fields at higher positions of the structure definition may be incorrectly accessed by applications.



[+] affected symbols: 156 (44.3%)

linux_dmabuf_buffer_get ( struct wl_resource* resource )
Field 'retval.compositor.touch_calibrator.view' in the return value (pointer) has base type 'struct weston_view'.
linux_dmabuf_buffer_get_user_data ( struct linux_dmabuf_buffer* buffer )
Field 'buffer.compositor.touch_calibrator.view' in 1st parameter 'buffer' (pointer) has base type 'struct weston_view'.
linux_dmabuf_buffer_send_server_error ( struct linux_dmabuf_buffer* buffer, char const* msg )
Field 

Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-03-13 Thread Carlos Henrique Lima Melara
Hi,

On Wed, Mar 13, 2024 at 05:42:29PM +0100, Dylan Aïssi wrote:
> Hi,
> 
> Le mer. 13 mars 2024 à 16:05, Carlos Henrique Lima Melara
>  a écrit :
> >
> > > I can try this week to prepare an updated package in a dedicated branch
> > > in salsa, so you can test it. Then, if everything is okay, we could fill
> > > the request to the release team.
> >
> > Sure, just let me know if you need help with anything and/or when the
> > packaging is ready for testing.
> 
> Ready for testing at:

That was fast :-)

> https://salsa.debian.org/xorg-team/wayland/weston/-/tree/debian-10.0
> I just realized the branch name is confusing...

Might be a bit confusing with Debian buster (a.k.a. Debian 10), yes
hahahhaah.

I can start testing today, but I think we should wait until the weekend
to be sure enough for filling the bug against the release team. Would
that be okay?

> Best,
> Dylan

Cheers,
Charles


signature.asc
Description: PGP signature


Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-03-13 Thread Dylan Aïssi
Hi,

Le mer. 13 mars 2024 à 16:05, Carlos Henrique Lima Melara
 a écrit :
>
> > I can try this week to prepare an updated package in a dedicated branch
> > in salsa, so you can test it. Then, if everything is okay, we could fill
> > the request to the release team.
>
> Sure, just let me know if you need help with anything and/or when the
> packaging is ready for testing.

Ready for testing at:
https://salsa.debian.org/xorg-team/wayland/weston/-/tree/debian-10.0
I just realized the branch name is confusing...

Best,
Dylan



Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-03-13 Thread Carlos Henrique Lima Melara
Hi,

On Tue, Mar 12, 2024 at 10:10:06PM +0100, Dylan Aïssi wrote:
> Hello,
> 
> Le mar. 12 mars 2024 à 20:45, Carlos Henrique Lima Melara
>  a écrit :
> >
> > Taking this into consideration and the outcome of Init systems and
> > systemd GR [3], I'd like to check with you the possibility of enabling the
> > support for libseat launcher in stable via a proposed-updates upload to
> > bookworm.
> 
> I'm not against that, but we will have to convince the release team that
> it won't introduce new bugs. That means we have to fill a bug report
> against the pseudo-package "release.debian.org".

Yeah... Though I thought it was better to first reach the maintainers
with the proposal before spending a long time testing stuff to see if
this option would break something.

And also weston has built-in tests which should help to convince them.

> If we are going to touch the package in Bookworm, I would like to try
> pushing the last bugfix release of the serie 10.0. It was a private
> request from upstream but I didn't realized that there were very few
> changes in the bugfix releases, it's worth a try. What do you think?

I'm all in on this, I think it's going to make a more compeling case for
the release team (although I only did CVE fixes to stable, not patch
releases). It's very few commits, so I think it shouldn't be
problematic.

> I can try this week to prepare an updated package in a dedicated branch
> in salsa, so you can test it. Then, if everything is okay, we could fill
> the request to the release team.

Sure, just let me know if you need help with anything and/or when the
packaging is ready for testing.

> > I did rebuild bookworm's version with the option enabled and tested it a
> > bit in my notebook. I've also used abi-compliance-checker to check if
> > this could have caused any ABI change in libweston and it didn't. I'll
> > provide the debdiff output for you to check.
> >
> > Also, should you answer positively, I can do a more exhaustive testing
> > and check if we don't introduce any errors when running with elogind and
> > systemd-logind.
> 
> This will be very useful to convince the release team.

Hopefully.

> Best regards,
> Dylan

Cheers and thanks!
Charles


signature.asc
Description: PGP signature


Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-03-12 Thread Dylan Aïssi
Hello,

Le mar. 12 mars 2024 à 20:45, Carlos Henrique Lima Melara
 a écrit :
>
> Taking this into consideration and the outcome of Init systems and
> systemd GR [3], I'd like to check with you the possibility of enabling the
> support for libseat launcher in stable via a proposed-updates upload to
> bookworm.

I'm not against that, but we will have to convince the release team that
it won't introduce new bugs. That means we have to fill a bug report
against the pseudo-package "release.debian.org".

If we are going to touch the package in Bookworm, I would like to try
pushing the last bugfix release of the serie 10.0. It was a private
request from upstream but I didn't realized that there were very few
changes in the bugfix releases, it's worth a try. What do you think?

I can try this week to prepare an updated package in a dedicated branch
in salsa, so you can test it. Then, if everything is okay, we could fill
the request to the release team.

> I did rebuild bookworm's version with the option enabled and tested it a
> bit in my notebook. I've also used abi-compliance-checker to check if
> this could have caused any ABI change in libweston and it didn't. I'll
> provide the debdiff output for you to check.
>
> Also, should you answer positively, I can do a more exhaustive testing
> and check if we don't introduce any errors when running with elogind and
> systemd-logind.

This will be very useful to convince the release team.

Best regards,
Dylan



Bug#1066112: weston: Enable support to libseat launcher in weston 10

2024-03-12 Thread Carlos Henrique Lima Melara
Source: weston
Version: 10.0.1-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: carlos.mel...@toradex.com

Dear Maintainers, hi.

First of all, thanks for maintaining weston in Debian.

Weston 10 is using the default build options set by upstream plus
screenshare and systemd features enabled via a debian/rules override of
dh_auto_configure. This basically covers the major cases for PCs and
servers, but for embedded systems and people not wanting to use systemd
(and logind), this is a problem.

Weston has support for using libseat for seat management/launching
weston via the launcher-libseat option (it's turned off by default in
meson_options.txt), but weston 11 libseat launcher became the default [1]
and recently (weston 12) the libseat launcher has become the one and
only official launcher supported by upstream weston [2].

Taking this into consideration and the outcome of Init systems and
systemd GR [3], I'd like to check with you the possibility of enabling the
support for libseat launcher in stable via a proposed-updates upload to
bookworm.

I did rebuild bookworm's version with the option enabled and tested it a
bit in my notebook. I've also used abi-compliance-checker to check if
this could have caused any ABI change in libweston and it didn't. I'll
provide the debdiff output for you to check.

Also, should you answer positively, I can do a more exhaustive testing
and check if we don't introduce any errors when running with elogind and
systemd-logind.

Cheers,
Charles

[1] 
https://www.collabora.com/news-and-blog/news-and-events/weston-11-whats-new-whats-next.html
[2] 
https://www.collabora.com/news-and-blog/news-and-events/weston-12-highlights-and-changes.html
[3] https://www.debian.org/vote/2019/vote_002

P.S. I don't think this system info is going to help since I've built in
bookworm chroot.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -u weston-10.0.1/debian/changelog weston-10.0.1/debian/changelog
--- weston-10.0.1/debian/changelog
+++ weston-10.0.1/debian/changelog
@@ -1,3 +1,11 @@
+weston (10.0.1-1+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * debian/control: add libseat-dev to Build-Depends.
+  * debian/rules: enable libseat support. (Closes: #)
+
+ -- Carlos Henrique Lima Melara   Tue, 12 Mar 2024 
12:54:10 -0300
+
 weston (10.0.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -u weston-10.0.1/debian/control weston-10.0.1/debian/control
--- weston-10.0.1/debian/control
+++ weston-10.0.1/debian/control
@@ -26,6 +26,7 @@
libpixman-1-dev (>= 0.25.2),
libpipewire-0.3-dev,
libpng-dev,
+   libseat-dev,
libsystemd-dev,
libudev-dev (>= 136),
libva-dev,
diff -u weston-10.0.1/debian/rules weston-10.0.1/debian/rules
--- weston-10.0.1/debian/rules
+++ weston-10.0.1/debian/rules
@@ -2,7 +2,8 @@
 
 override_dh_auto_configure:
dh_auto_configure -- -Dscreenshare=true \
-   -Dsystemd=true
+   -Dsystemd=true \
+   -Dlauncher-libseat=true
 
 override_dh_auto_test:
mkdir -p $(CURDIR)/debian/tmp/tmp/xdgruntimedir