Public bug reported: Thermald is a userspace daemon that monitors and controls temperatures on x86 devices such as laptops, PCs and servers. It detects if a system has reached a specific temperature and will active various available cooling controls/methods to try and cool the system. Thermald also allows user defined per-system configuration to tweak CPU cooling policy which is useful on hardware that has poor BIOS controlled thermal management or suffers from thermal overrun due to poor cooling design.
With the move to using the more efficient intel_pstate driver, CPUs are sometimes driven harder than previous CPU governors so it is also helpful to use thermald in conjunction with this kernel configuration to ensure CPU thermal overrun does not occur. With the kernel moving to the intel_pstate driver by default it makes sense for thermald to be installed on x86 specific H/W to perform better thermal control. Below are all the answers to the UbuntuMainInclusionRequirements sections. I will highlight the following known violations: 1) a debian/watch does not currently exist with this package. As I am the Debian maintainer I will add this next time I upload the package (hopefully by end of this week) 2) as this is a daemon, the package needs extra scrutiny from the Security folks Below are my answers to the various main inclusion requirements, marked by a * prefix: Thermald MIR checklist (Wed Feb 12 15:21:08 GMT 2014) Availability: The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on. * Yes - http://packages.ubuntu.com/trusty/admin/thermald Rationale: There must be a certain level of demand for the package, for example: The package is useful for a large part of our user base. * Yes - x86 users (i386, amd64) and will ensure CPUs don't overheat, works in conjunction with intel_pstate CPU governor and RAPL. The package is a new build dependency or dependency of a package that we already support (additionally, the official image builder requires all used packages be in main). * Yes, the Trusty kernel with intel_pstate enabled The package helps meet a specific Blueprint goal. * Yes, Overall goal of improved power management and reducing thermal overrun The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set. * Not applicable Security: The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks. Quality assurance: After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading. * Will auto start as a daemon, can be stopped/start like any typical daemon. * Man page is provided covering all the features * Thermnald works with zero configuration mode by default. There is an XML configuration file for user defined configuration tweaks if a system has buggy or broken ACPI or for finer tuning. This is also documented in the provided man pages. The package must not ask debconf questions higher than medium if it is going to be installed by default. The debconf questions must have reasonable defaults. * Does not apply. There are no long-term outstanding bugs which affect the usability of the program to a major degree. To support a package, we must be reasonably convinced that upstream supports and cares for the package. * No long term bugs, it is a relatively new package * I have been working with upstream (Intel) and I have a good working relationship with the lead developer. Fixes land within 2-3 days into the main repository and developer is responsive to bug reports/fixes. The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking systems must be evaluated. Links to these bug trackers need to be provided in the MIR report. Important bugs must be pointed out and discussed in the MIR report. Bug reports: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=thermald;dist=unstable Project bug tracker: https://github.com/01org/thermal_daemon/issues Resolved bugs in Debian: * 737093 thermald: deamon eats 100 percent CPU time * 734832 thermald exits why trying to use systemd init * 738719 thermald install and improve systemd init (fixed 12th Feb 2014) * 734786 thermald: FTBFSL No rule to make target `man/thermald.1` The package is maintained well in Debian/Ubuntu (check out the Debian PTS) * Yes (by Colin King) http://packages.qa.debian.org/t/thermald.html May need some other input on this as I'm speaking for myself. The package should not deal with exotic hardware which we cannot support. * Only works on x86 platforms, and will handle H/W that thermald supports, other H/W is ignored by thermald if it can't support it. If the package ships a test suite, and there is no obvious reason why it cannot work during build (e. g. it needs root privileges or network access), it should be run during package build, and a failing test suite should fail the build. * Not applicable The package uses a debian/watch file whenever possible. In cases where this is not possible (e. g. native packages), the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file. * NONE, I will add that next time I update the package UI standards: (generally only for user-facing applications) End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build. End-user applications must ship a standard conformant desktop file. * Not applicable, it is a daemon Dependencies: All build and binary dependencies (including Recommends:) must be satisfyable in main (i. e. the preferred alternative must be in main). If not, these dependencies need a separate MIR report (this can be a separate bug or another task on the main MIR bug) * debhelper - Yes * dh-autoreconf - Yes * quilt - Yes * autoconf - Yes * libglib2.0-dev - Yes * libdbus-1-dev - Yes * libdbus-glib-1-dev - Yes * libxml2-dev - Yes * dh-systemd - Yes Standards compliance: The package should meet the FHS and Debian Policy standards. Major violations should be documented and justified. Also, the source packaging should be reasonably easy to understand and maintain. * I believe so, yes. Maintenance: The package must have an acceptable level of maintenance corresponding to its complexity: Simple packages (e.g. language bindings, simple Perl modules, small command-line programs, etc.) might not need very much maintenance effort, and if they are maintained well in Debian we can just keep them synced More complex packages will usually need a developer or team of developers paying attention to their bugs, whether that be in Ubuntu or elsewhere (often Debian). Packages that deliver major new headline features in Ubuntu need to have commitment from Ubuntu developers willing to spend substantial time on them. * Falls into the simple package category. Colin King is the Debian maintainer, so it can be sync'd easily. We've had success in the last 2 months with maintainence and turning around issues responsively. All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact. * Yes, Canononical Kernel Team https://launchpad.net/~canonical-kernel-team Background information: The package descriptions should explain the general purpose and context of the package. Additional explanations/justifications should be done in the MIR report. * Yes, package description covers the scope of the package If the package was renamed recently, or has a different upstream name, this needs to be explained in the MIR report. * Not applicable Security checks: Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package: http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword * No CVEs found http://secunia.com/advisories/search/: search for the package as a keyword * No security advisories found Ubuntu CVE Tracker http://people.ubuntu.com/~ubuntu-security/cve/main.html * No http://people.ubuntu.com/~ubuntu-security/cve/universe.html * No http://people.ubuntu.com/~ubuntu-security/cve/partner.html * No Check for security relevant binaries. If any are present, this requires a more in-depth security review. Executables which have the suid or sgid bit set. * Not applicable Executables in /sbin, /usr/sbin. * Applicable. This requires security review Packages which install daemons (/etc/init.d/*) * Applicable. This requires security review Packages which open privileged ports (ports < 1024). * Not applicable Add-ons and plugins to security-sensitive software (filters, scanners, UI skins, etc) * Not applicable ** Affects: thermald (Ubuntu) Importance: Undecided Assignee: MIR approval team (ubuntu-mir) Status: New ** Description changed: Thermald is a userspace daemon that monitors and controls temperatures on x86 devices such as laptops, PCs and servers. It detects if a system has reached a specific temperature and will active various available cooling controls/methods to try and cool the system. Thermald also - allows user defined per-system configuration to lower tweak CPU cooling - policy which is useful on hardware that has poor BIOS controlled thermal + allows user defined per-system configuration to tweak CPU cooling policy + which is useful on hardware that has poor BIOS controlled thermal management or suffers from thermal overrun due to poor cooling design. With the move to using the more efficient intel_pstate driver, CPUs are sometimes driven harder than previous CPU governors so it is also helpful to use thermald in conjunction with this kernel configuration to ensure CPU thermal overrun does not occur. With the kernel moving to the intel_pstate driver by default it makes sense for thermald to be installed on x86 specific H/W to perform better thermal control. Below are all the answers to the UbuntuMainInclusionRequirements sections. I will highlight the following known violations: 1) a debian/watch does not currently exist with this package. As I am the Debian maintainer I will add this next time I upload the package (hopefully by end of this week) 2) as this is a daemon, the package needs extra scrutiny from the Security folks - - Below are my answers to the various main inclusion requirements, marked by a * prefix: - - Thermald MIR checklist (Wed Feb 12 15:21:08 GMT 2014) + Below are my answers to the various main inclusion requirements, marked + by a * prefix: + + Thermald MIR checklist (Wed Feb 12 15:21:08 GMT 2014) Availability: The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on. * Yes - http://packages.ubuntu.com/trusty/admin/thermald - + Rationale: There must be a certain level of demand for the package, for example: - The package is useful for a large part of our user base. - * Yes - x86 users (i386, amd64) and will ensure CPUs don't overheat, works - in conjunction with intel_pstate CPU governor and RAPL. - - The package is a new build dependency or dependency of a package that we - already support (additionally, the official image builder requires all - used packages be in main). - * Yes, the Trusty kernel with intel_pstate enabled - - The package helps meet a specific Blueprint goal. - * Yes, Overall goal of improved power management and reducing thermal - overrun - The package replaces another package we currently support and promises - higher quality and/or better features, so that we can drop the old - package from the supported set. - * Not applicable + The package is useful for a large part of our user base. + * Yes - x86 users (i386, amd64) and will ensure CPUs don't overheat, works + in conjunction with intel_pstate CPU governor and RAPL. + + The package is a new build dependency or dependency of a package that we + already support (additionally, the official image builder requires all + used packages be in main). + * Yes, the Trusty kernel with intel_pstate enabled + + The package helps meet a specific Blueprint goal. + * Yes, Overall goal of improved power management and reducing thermal + overrun + The package replaces another package we currently support and promises + higher quality and/or better features, so that we can drop the old + package from the supported set. + * Not applicable Security: The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in - the subsection Security checks. + the subsection Security checks. Quality assurance: - After installing the package it must be possible to make it working with a - reasonable effort of configuration and documentation reading. - * Will auto start as a daemon, can be stopped/start like any typical - daemon. - * Man page is provided covering all the features - * Thermnald works with zero configuration mode by default. There is - an XML configuration file for user defined configuration tweaks - if a system has buggy or broken ACPI or for finer tuning. This - is also documented in the provided man pages. - - The package must not ask debconf questions higher than medium if it is - going to be installed by default. The debconf questions must have - reasonable defaults. - * Does not apply. - - There are no long-term outstanding bugs which affect the usability of the - program to a major degree. To support a package, we must be reasonably - convinced that upstream supports and cares for the package. - * No long term bugs, it is a relatively new package - * I have been working with upstream (Intel) and I have a good working - relationship with the lead developer. Fixes land within 2-3 days into - the main repository and developer is responsive to bug reports/fixes. - - The status of important bugs in Debian's, Ubuntu's, and upstream's bug - tracking systems must be evaluated. Links to these bug trackers need to - be provided in the MIR report. Important bugs must be pointed out and - discussed in the MIR report. - - Bug reports: - https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=thermald;dist=unstable - Project bug tracker: - https://github.com/01org/thermal_daemon/issues - - Resolved bugs in Debian: - * 737093 thermald: deamon eats 100 percent CPU time - * 734832 thermald exits why trying to use systemd init - * 738719 thermald install and improve systemd init (fixed 12th Feb 2014) - * 734786 thermald: FTBFSL No rule to make target `man/thermald.1` - - The package is maintained well in Debian/Ubuntu (check out the Debian PTS) - * Yes (by Colin King) http://packages.qa.debian.org/t/thermald.html - May need some other input on this as I'm speaking for myself. - - The package should not deal with exotic hardware which we cannot support. - * Only works on x86 platforms, and will handle H/W that thermald supports, - other H/W is ignored by thermald if it can't support it. - - If the package ships a test suite, and there is no obvious reason why - it cannot work during build (e. g. it needs root privileges or network - access), it should be run during package build, and a failing test suite - should fail the build. - * Not applicable - - The package uses a debian/watch file whenever possible. In cases where - this is not possible (e. g. native packages), the package should either - provide a debian/README.source file or a debian/watch file (with comments - only) providing clear instructions on how to generate the source tar file. - * NONE, I will add that next time I update the package - - UI standards: (generally only for user-facing applications) - End-user applications must be internationalized (translatable), using - the standard intltool/gettext build and runtime system and produce a - proper PO template during build. - End-user applications must ship a standard conformant desktop file. - * Not applicable, it is a daemon - - Dependencies: - All build and binary dependencies (including Recommends:) must be - satisfyable in main (i. e. the preferred alternative must be in main). - If not, these dependencies need a separate MIR report (this can be a - separate bug or another task on the main MIR bug) - * debhelper - Yes - * dh-autoreconf - Yes - * quilt - Yes - * autoconf - Yes - * libglib2.0-dev - Yes - * libdbus-1-dev - Yes - * libdbus-glib-1-dev - Yes - * libxml2-dev - Yes - * dh-systemd - Yes - - Standards compliance: The package should meet the FHS and Debian Policy - standards. Major violations should be documented and justified. Also, the - source packaging should be reasonably easy to understand and maintain. - * I believe so, yes. - - Maintenance: The package must have an acceptable level of maintenance - corresponding to its complexity: - Simple packages (e.g. language bindings, simple Perl modules, small - command-line programs, etc.) might not need very much maintenance effort, - and if they are maintained well in Debian we can just keep them synced - - More complex packages will usually need a developer or team of - developers paying attention to their bugs, whether that be in Ubuntu or - elsewhere (often Debian). Packages that deliver major new headline - features in Ubuntu need to have commitment from Ubuntu developers - willing to spend substantial time on them. - - * Falls into the simple package category. Colin King is the Debian - maintainer, so it can be sync'd easily. We've had success in the - last 2 months with maintainence and turning around issues - responsively. - - All packages must have a designated "owning" team, regardless of - complexity, which is set as a package bug contact. - * Yes, Canononical Kernel Team - https://launchpad.net/~canonical-kernel-team - - Background information: - The package descriptions should explain the general purpose and context - of the package. Additional explanations/justifications should be done - in the MIR report. - * Yes, package description covers the scope of the package - - If the package was renamed recently, or has a different upstream name, - this needs to be explained in the MIR report. - * Not applicable + After installing the package it must be possible to make it working with a + reasonable effort of configuration and documentation reading. + * Will auto start as a daemon, can be stopped/start like any typical + daemon. + * Man page is provided covering all the features + * Thermnald works with zero configuration mode by default. There is + an XML configuration file for user defined configuration tweaks + if a system has buggy or broken ACPI or for finer tuning. This + is also documented in the provided man pages. + + The package must not ask debconf questions higher than medium if it is + going to be installed by default. The debconf questions must have + reasonable defaults. + * Does not apply. + + There are no long-term outstanding bugs which affect the usability of the + program to a major degree. To support a package, we must be reasonably + convinced that upstream supports and cares for the package. + * No long term bugs, it is a relatively new package + * I have been working with upstream (Intel) and I have a good working + relationship with the lead developer. Fixes land within 2-3 days into + the main repository and developer is responsive to bug reports/fixes. + + The status of important bugs in Debian's, Ubuntu's, and upstream's bug + tracking systems must be evaluated. Links to these bug trackers need to + be provided in the MIR report. Important bugs must be pointed out and + discussed in the MIR report. + + Bug reports: + https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=thermald;dist=unstable + Project bug tracker: + https://github.com/01org/thermal_daemon/issues + + Resolved bugs in Debian: + * 737093 thermald: deamon eats 100 percent CPU time + * 734832 thermald exits why trying to use systemd init + * 738719 thermald install and improve systemd init (fixed 12th Feb 2014) + * 734786 thermald: FTBFSL No rule to make target `man/thermald.1` + + The package is maintained well in Debian/Ubuntu (check out the Debian PTS) + * Yes (by Colin King) http://packages.qa.debian.org/t/thermald.html + May need some other input on this as I'm speaking for myself. + + The package should not deal with exotic hardware which we cannot support. + * Only works on x86 platforms, and will handle H/W that thermald supports, + other H/W is ignored by thermald if it can't support it. + + If the package ships a test suite, and there is no obvious reason why + it cannot work during build (e. g. it needs root privileges or network + access), it should be run during package build, and a failing test suite + should fail the build. + * Not applicable + + The package uses a debian/watch file whenever possible. In cases where + this is not possible (e. g. native packages), the package should either + provide a debian/README.source file or a debian/watch file (with comments + only) providing clear instructions on how to generate the source tar file. + * NONE, I will add that next time I update the package + + UI standards: (generally only for user-facing applications) + End-user applications must be internationalized (translatable), using + the standard intltool/gettext build and runtime system and produce a + proper PO template during build. + End-user applications must ship a standard conformant desktop file. + * Not applicable, it is a daemon + + Dependencies: + All build and binary dependencies (including Recommends:) must be + satisfyable in main (i. e. the preferred alternative must be in main). + If not, these dependencies need a separate MIR report (this can be a + separate bug or another task on the main MIR bug) + * debhelper - Yes + * dh-autoreconf - Yes + * quilt - Yes + * autoconf - Yes + * libglib2.0-dev - Yes + * libdbus-1-dev - Yes + * libdbus-glib-1-dev - Yes + * libxml2-dev - Yes + * dh-systemd - Yes + + Standards compliance: The package should meet the FHS and Debian Policy + standards. Major violations should be documented and justified. Also, the + source packaging should be reasonably easy to understand and maintain. + * I believe so, yes. + + Maintenance: The package must have an acceptable level of maintenance + corresponding to its complexity: + Simple packages (e.g. language bindings, simple Perl modules, small + command-line programs, etc.) might not need very much maintenance effort, + and if they are maintained well in Debian we can just keep them synced + + More complex packages will usually need a developer or team of + developers paying attention to their bugs, whether that be in Ubuntu or + elsewhere (often Debian). Packages that deliver major new headline + features in Ubuntu need to have commitment from Ubuntu developers + willing to spend substantial time on them. + + * Falls into the simple package category. Colin King is the Debian + maintainer, so it can be sync'd easily. We've had success in the + last 2 months with maintainence and turning around issues + responsively. + + All packages must have a designated "owning" team, regardless of + complexity, which is set as a package bug contact. + * Yes, Canononical Kernel Team + https://launchpad.net/~canonical-kernel-team + + Background information: + The package descriptions should explain the general purpose and context + of the package. Additional explanations/justifications should be done + in the MIR report. + * Yes, package description covers the scope of the package + + If the package was renamed recently, or has a different upstream name, + this needs to be explained in the MIR report. + * Not applicable Security checks: - Check how many vulnerabilities the package had in the past and how they - were handled by upstream and the Debian/Ubuntu package: - - http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword - * No CVEs found - - http://secunia.com/advisories/search/: search for the package as a keyword - * No security advisories found - - Ubuntu CVE Tracker - http://people.ubuntu.com/~ubuntu-security/cve/main.html - * No - http://people.ubuntu.com/~ubuntu-security/cve/universe.html - * No - http://people.ubuntu.com/~ubuntu-security/cve/partner.html - * No - - Check for security relevant binaries. If any are present, this - requires a more in-depth security review. - - Executables which have the suid or sgid bit set. - * Not applicable - - Executables in /sbin, /usr/sbin. - * Applicable. This requires security review - - Packages which install daemons (/etc/init.d/*) - * Applicable. This requires security review - - Packages which open privileged ports (ports < 1024). - * Not applicable - - Add-ons and plugins to security-sensitive software (filters, - scanners, UI skins, etc) - * Not applicable + Check how many vulnerabilities the package had in the past and how they + were handled by upstream and the Debian/Ubuntu package: + + http://cve.mitre.org/cve/cve.html: Search in the National Vulnerability Database using the package as a keyword + * No CVEs found + + http://secunia.com/advisories/search/: search for the package as a keyword + * No security advisories found + + Ubuntu CVE Tracker + http://people.ubuntu.com/~ubuntu-security/cve/main.html + * No + http://people.ubuntu.com/~ubuntu-security/cve/universe.html + * No + http://people.ubuntu.com/~ubuntu-security/cve/partner.html + * No + + Check for security relevant binaries. If any are present, this + requires a more in-depth security review. + + Executables which have the suid or sgid bit set. + * Not applicable + + Executables in /sbin, /usr/sbin. + * Applicable. This requires security review + + Packages which install daemons (/etc/init.d/*) + * Applicable. This requires security review + + Packages which open privileged ports (ports < 1024). + * Not applicable + + Add-ons and plugins to security-sensitive software (filters, + scanners, UI skins, etc) + * Not applicable -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1279388 Title: [MIR] thermald To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1279388/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
