Hi Charles,
Sorry for not answering before.
Le jeu. 4 avr. 2024 à 16:04, Carlos Henrique Lima Melara
<charlesmel...@riseup.net> 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
