As theses are new macros, we can make an exception and backports them to xdt 4.18. Don't forget to bump minimal xdt versions in autogen :)
Yes, others distros haven't noticed the problem because they don't re run autoreconf.
Le 16 octobre 2023 11:31:17 GMT+02:00, "Gaël Bonithon" <trash.paradise@protonmail.com> a écrit :
I'd vote for 2): I don't think there's much risk either and we've been testing these macros for a while now with xfdesktop, xfce4-notifyd and more recently xfce4-panel, at least.
Cheers,
Gaël
------- Original Message -------
On Monday, October 16th, 2023 at 5:58 AM, Alex <acs82@gmx.de> wrote:
>
> Hi all,
>
>
>
> thanks for the forward Brian! As well added Skunnyk and Andre.
>
>
>
> Personally I would go for the more conservative 1) to prevent possible further trouble with them on the stable branch ... maybe with a comment to swap them out for the xfce-4.20 official macros, once xfce4.20 is released.
>
>
>
> Though I did not look into the Makros in detail ... if you are sure that 2) will be save / will not have side effects, it as well would be fine with it.
>
> Cheers, Alex
>
>
> Am 16.10.23 um 03:51 schrieb Brian Tarricone:
>
> > Gah, sorry about that, I didn't even think of the fact that distros would need the newer 4.19 dev-tools package for packaging.>> CC'd Alex; Alex, for some more context (some of it got snipped): we've started depending on some macros I added to xfce4-dev-tools in the 4.19.x series (the XDT_CHECK_OPTIONAL_FEATURE stuff), but in stable versions of things (xfce4-terminal, xfce4-notifyd). Turns out that's making things difficult for packagers.>> So I think we have two good options:>> 1) We can put the new m4 macros in a .m4 file, prefix them with something else so they don't conflict, and copy it into each project that uses them and wants to do stable releases for now. Then those modules can run against xfce4-dev-tools 4.18 again.>> 2) We can backport the new macros to the 4.18 branch of xfce4-dev-tools. Since they're just additions, I don't think there's much risk of problems.>> Ok ok, there's also 3) go back to manually listing out the dependencies in each configure.ac and gating X11/Wayland support on them. But I don't feel like doing that ;)>> Gaël, Alex, what do you think? Feel free to CC anyone else who should weigh in. Personally I think #2 is the easiest, especially as more non-core modules want to support Wayland and need compile-time support for it, but not sure putting new macros in the stable series of xfce4-dev-tools is ok to do.>> -brian>> On Sun, Oct 15, 2023, at 15:11, Yves-Alexis Perez wrote:
>
> >
> > On Sun, 2023-10-15 at 21:08 +0000, Gaël Bonithon wrote:
> > >>>> We have the same issue for xfce4-notifyd but then I assumed 0.9 was the
> > >>>> development branch leading to a 0.10 release for Xfce 4.20. So we pushed
> > >>>> it to
> > >>>> experimental without too much fuss.
> > >>>
> > >>> Xfce4-notifyd 0.9.x are not dev versions as far as I know.
> >
> > Well that doesn't change the fact that we can't upload it to unstable now :)
> > >>>
> > >>>> Well, if you have it and it's sensible, yes sure.
> > >>>
> > >>> See the attached patch. Not all XDT_CHECK_OPTIONAL_FEATURE features are
> > >>> reproduced, but it should be enough. And since it has a limited impact, it
> > >>> should continue to apply until Xfce 4.20.
> >
> > Thanks, I'll try that and report back (also, no need to encrypt direct mail,
> > since it's sent in cleartext to a mailing list anyway).
> >
> > Regards,
> >
>