Comment 2 for bug 1853830
Revision history for this message
| Sebastien Bacher (seb128) wrote Re: [MIR] gamemode | #2 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
Hey Didier, thanks for the review!
> 1/ One lintian warning that I’m fine to ignore (but will be better to fix it in lintian or have an override):
> W: gamemode source: incorrect-
Proposed fix to Debian in https:/
> 2/ I know that the soname is still at 0. However, I would like to have symbols files present with makeshlibs called -c4 for both libs please.
> I find it concerning now that release 1.X is reached, we still have an unstable ABI and it should be tracked.
> I saw there is an explicit lintian override for skipping them. Is there any reasons which is still valid and we don’t want to track the API?
I opened a bug on the BTS to start the discussion about that
https:/
> 3/ There are now 2 (very recent, I admit :p) bugs in launchpad.
The first one was about 19.10 and fixed in focal (the packaging was buggy), the 1.5 update was done in Debian over the w.e and synced to focal now.
> - However, I don’t understand why the systemd service is called with -l (log to syslog), which is out default for systemd service
> (the journal forwards to syslog, even for user services). The day we want to remove syslog completely, it will prevent having to patch it.
Reported with a mp to frop the -l upstream on https:/
> 5/ I am not completely sure why the 2 -dev are separated. However, as the only libgamemodeauto-dev ships some headers,
> are you sure that we can build against libgamemodeauto0 without having those headers installed?
> If not, libgamemodeauto-dev should dep on libgamemode-dev.
...
> 6/ I think libmode* should recommends, provides some alternative or at least suggests the package having the daemon.
I will have a look to those/talk to the Debian
> When those are fixed (in particular the update to 1.5), I would like to request a security review as this daemon is root executed by an user command.
We got the 1.5 update done, the bug closed and the ball rolling on the other issues, I guess that's good enough to bounce to security while the remaining packaging questions are discussed?