[MIR] tlp

[Dimitri John Ledkov]

Dear OEM team please complete this MIR request for tlp....
  (https://github.com/linrunner/TLP)

Documentation for MIR is at https://wiki.ubuntu.com/MainInclusionProcess please see requirements section, and fill out the below template with information.

[Availability]
tlp is available in universe.

[Rationale]
tlp is the tool to configure system power behaviours. it's the tool used
in projects that need power consumption criteria.

[Security]
tlp is a tool to configure the system based on config file
(mostly kernel parameter).
It's developer is still active. Given the way it work, there
seems no CVE exists yet.

[Quality assurance]
oem team use this tool more than 2 years, and it works fine along
the way.
upstream bugs are mostly kind of feature requests:
  https://github.com/linrunner/TLP/issues
Due to it's nature, tlp usually expose kernel bug. There usually
no major bug in tlp itself.

[Dependencies]
it depends on ethtool which already in main.
 (note that tlp source package generate tlp and tlp-rdw

[Standards compliance]
tlp exists in debian for years. It's quite standard shell scripts.

[Maintenance]
owning team: https://launchpad.net/~oem-solutions-engineers

[Background information]
For project that demand power consumption criteria, tlp is the tool we
use the configure the kernel parameters so that it can pass standard like
energy-star, etc. Given we'd like close the gap between oem and stock ubuntu, it should be the right way to switch to main.

[Dimitri John Ledkov (xnox)]

@OEM Solutions Group

Please complete the MIR for tlp, such that we can get it into main.

[Didier Roche-Tolomelli (didrocks)]

Adding mir team subscription so that it shows up on our MIR radar and setting it to incomplete as per MIR process.

Please, once ready, set it back to New and unassigned yourself so that we can evaluate the MIR.

Related bug: https://bugs.launchpad.net/ubuntu/+source/oem-somerville-melisa-meta/+bug/1888498

[Christian Ehrhardt  (paelzer)]

[Summary]
This looks mostly ok, it essentially is just an advanced shell script.

A 473 line config file suggests plenty of hidden complexity and special
cases, so with this becoming fully supported the owning team needs to be aware
of some hard debugging hours.
At the same time there are no self-tests - so I feel this might break at any
time and then will need attention.
The open Debian bugs kind of reflect this.
Nothing to stop the MIR, but I wanted to raise awareness for this.

Required before ack:
- The package has a no team bug subscriber, this is a hard requirement

Recommended before ack:
- Some shellcheck errors (mostly sh vs bash things) are worth to clean up.
- think how to add at least some regular testing for this package

MIR Team Ack once the conditions above are fulfilled.

There seems to be no inherent security risk, for this MIR no security review
is needed.

[Duplication]
There are a few kernel interfaces, but no package providing a configurable
place. The UI configs e.g. power options in gnome - do not cover these options.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - in main are hdparm wireless-tools pci-utils rfkill usbutils ethtool
    and network-manager
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

[Common blockers]
OK:
- does not FTBFS currently (no actual build)
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- no new python2 dependency

Problems:
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
=> I'm unsure what tests we could do, due to the nature testing this right
   to have a vast matrix of different bare metal systems

- The package has a no team bug subscriber, this is a hard requirement

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is ok
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build (this is only shell)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

Problems:
- th...

[linrunner (linrunner)]

Hi, i'm TLP's upstream/author.

> but shellcheck isn't entirely happy
I do shellchecks for every TLP release (there even is a Makefile target for it) but didn't re-check with 20.04 before the 1.3 release. My bad. Feel free to make use of my commit:

https://github.com/linrunner/TLP/commit/5934be84c8d934d8d37b73db28a291751d1f6831

There is nothing critical, the SC2034's are all for sysfs paths/filenames that never contain blanks.

> so I feel this might break at any time and then will need attention. The open Debian bugs kind of reflect this.

Of course any software may break at any time ;). The very few Debian and Ubuntu bugs so far only tell that TLP may expose malfunctions in kernel driver power saving, which is to be expected but not relevant when talking about hardware enabled OEM laptops with customized TLP configuration.

The majority of entries in TLP's upstream issue tracker is about kernel issues too.

I can say without immodesty that TLP itself breaks very rarely.

[Christian Ehrhardt  (paelzer)]

>
> Hi, i'm TLP's upstream/author.
>

Hello,
glad to hear from you which implies that you have an eye on these issues as
well - that is great.

> I do shellchecks for every TLP release (there even is a Makefile target
> for it) but didn't re-check with 20.04 before the 1.3 release. My bad. Feel
> free to make use of my commit:
> [...]

Yes I have seen that none are critical which is why I have put it to the
optional list of things to look at.

[...]

I can say without immodesty that TLP itself breaks very rarely.
>

That is great to hear (well, not for the kernel) but great still for TLP
itself.
Overall you relieve some of my concerns about code complexity with these
statements.
But those were not stopping this process anyway.

Thanks for your feedback linrunner!

@Linrunner - one more question for you - do you also have access to a test
matrix of different HW systems e.g. to test a new release on many different
HW/Kernel combos?
Sounds like overkill in terms of space/power/money requirement, but you
know - in a perfect world - such a thing would exist. Seeing you here I
thought I might ask.

In General, still what is missing here for promotion is a team subscriber,
I'll ask around in todays MIR meeting if one team planned to own it.

[linrunner (linrunner)]

Nope. I don't have a "HW/kernel test matrix" (beyond a few personal ThinkPads). This is beyond the scope and ressources of a small project.

If i understood correctly, the OEM team wants to use TLP for hardware enablement. So at least for certified hardware the corresponding Ubuntu release is tested and eventually a custom TLP configuration is provided.

Of course this won't cover regressions from release or kernel upgrades.

For ordinary users running into issues there is plenty of documentation including a troubleshooting guide: https://linrunner.de/tlp/support/troubleshooting.html

[Alex Tu (alextu)]

Yes, we adopted TLP for factory image on certified machines from Bionic.
And we are adopting TLP to both factory image and stock Ubuntu on certified machines from Focal.
Idealy, we have those machines in SRU pool so that TLP could be tested during every SRU cycle.

For the certified machine, we applied customized TLP configuration [1] with more aggressive setting to gain more powersaving. Of cause, the malfunction driver issue in powersaving also be covered by the same package.

[1] https://code.launchpad.net/~oem-solutions-engineers/pc-enablement/+git/oem-fix-misc-cnl-tlp-estar-conf

[Dimitri John Ledkov (xnox)]

~oem-solutions-engineers will handle certified machines (and/or specific customizations settings)

~foundations-bugs is subscribed and will handle any Ubuntu Archive / main issues.

[Christian Ehrhardt  (paelzer)]

Thanks Dimitri.

Everything ready, per [1] this is Fix Committed now just waiting for an Archive admin to promote it.

[1]: https://wiki.ubuntu.com/MainInclusionProcess?action=show&redirect=MIRTeam#Process_states

[Steve Langasek (vorlon)]

Override component to main
tlp 1.3.1-2 in groovy: universe/misc -> main
tlp 1.3.1-2 in groovy amd64: universe/utils/optional/100% -> main
tlp 1.3.1-2 in groovy arm64: universe/utils/optional/100% -> main
tlp 1.3.1-2 in groovy armhf: universe/utils/optional/100% -> main
tlp 1.3.1-2 in groovy i386: universe/utils/optional/100% -> main
tlp 1.3.1-2 in groovy ppc64el: universe/utils/optional/100% -> main
tlp 1.3.1-2 in groovy riscv64: universe/utils/optional/100% -> main
tlp 1.3.1-2 in groovy s390x: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy amd64: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy arm64: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy armhf: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy i386: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy ppc64el: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy riscv64: universe/utils/optional/100% -> main
tlp-rdw 1.3.1-2 in groovy s390x: universe/utils/optional/100% -> main
Override [y|N]? y
15 publications overridden.

[Yuan-Chen Cheng (ycheng-twn)]

Shall we also merge to main in focal?

For now, the tlp version in groovy is the same as the one in focal.