> However, I don't see how we can argue that dropping FAN support is
> *not* a regression, even if the kernel we ship does not support it.
I understand.
I guess the situation is a bit particular here. If the official kernel doesn't support it -- something Ubuntu-specific, not upstreamed -- it means Ubuntu FAN cannot be used: there is no way to even validate that these patches work on Ubuntu 24.04. The regression would be more on the kernel side :)
>> and dropping these patches would stop the diversion with Debian?
>
> That's not a goal of our SRU process. We can always realign with
> Debian during the next devel cycle.
Good point. I just wanted to suggest that dropping these patches could be seen as a "safer approach" as it is closer to the upstream version, what is on Debian and other distributions.
> The package does seem to include this in its autopkgtests
> (debian/tests/testsuite.sh), so I think we have that coverage.
Oh, I missed that, thank you for having checked! Good news then!
> However, I don't see how we can argue that dropping FAN support is
> *not* a regression, even if the kernel we ship does not support it.
I understand.
I guess the situation is a bit particular here. If the official kernel doesn't support it -- something Ubuntu-specific, not upstreamed -- it means Ubuntu FAN cannot be used: there is no way to even validate that these patches work on Ubuntu 24.04. The regression would be more on the kernel side :)
>> and dropping these patches would stop the diversion with Debian?
>
> That's not a goal of our SRU process. We can always realign with
> Debian during the next devel cycle.
Good point. I just wanted to suggest that dropping these patches could be seen as a "safer approach" as it is closer to the upstream version, what is on Debian and other distributions.
> The package does seem to include this in its autopkgtests tests/testsuite .sh), so I think we have that coverage.
> (debian/
Oh, I missed that, thank you for having checked! Good news then!