MIRTeam
Differences between revisions 41 and 64 (spanning 23 versions)
|
Size: 8450
Comment:
|
← Revision 64 as of 2020-03-24 15:53:06 ⇥
Size: 32
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; background-repeat: no-repeat; background-position: 98% 0.5ex; margin: 0 0 1em 1em; padding: 0.5em;"><<TableOfContents>>|| == Introduction == The Ubuntu MIR Team reviews packages for promotion from universe to main. See MainInclusionProcess for information on how to request an MIR. == Reviewing == The primary decision a reviewer is making is '''"Will this package be well maintained in main?"''' The following guidelines are just ways to help you answer to that question. === Duplication === One easy way to avoid the burden of maintaining the package is to not use it in the first place! If a package is pulling in some random jpeg parsing library that needs a MIR, maybe it makes more sense to patch the package to just use libjpeg instead. Keep an eye out for duplicated functionality in main, since that makes bug fixing and security reviewing that much harder. === Embedded sources and static linking === Embedding a library source increases the maintenance burden of a package since that source needs to be maintained separately from the source in the Ubuntu archive. If a source embeds another package, in general the embedded package should not be used and the packaging should be modified to use the Ubuntu archive version. When this is not possible, the security team must agree to using the embedded source. Similarly, when a binary from one source package statically links to libraries from another source package from the archive, when those libraries are updated the statically linked binaries must be rebuilt with the updated libraries to receive the fix, which increases the maintenance burden. For this reason, static linking in archive builds is discouraged unless static linking is required for the package in question to function correctly (eg, an integrity scanner). ==== golang ==== golang 1.4 packages and earlier could only statically compile their binaries. golang 1.5 introduces `-buildmode=shared` to build shared libraries and `-linkshared` to dynamically link against shared libraries. Once golang shared library support is enabled for archive builds by default, there will be no extra maintenance concerns (unfortunately golang 1.5 lacks arm64 shared library support, but this is coming). In general, statically compiled binaries are not suitable for the Ubuntu archive because they increase the maintenance burden significantly. During the transition period to shared libraries for archive builds and so long as the number of packages remains low, strategic (to Canonical) golang projects that statically build their binaries may be considered for MIR provided they follow the guidelines below. '''IMPORTANT''': during [[http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/README.built_using|this interim period]], the requesting team must state their commitment to testing no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release. === Security === Determine if the package may have security implications (has a history of CVEs, runs a daemon as root, uses webkit^1,2^, uses lib*v8 directly, parses data formats, opens a port, processes arbitrary web content, uses centralized online accounts, integrates arbitrary javascript into the desktop, deals with system authentication (eg, pam), etc). Err on the side of caution. If the package is security sensitive, you have two options. You can either review as much as you can and then assign to the ubuntu-security team. Or you can immediately re-assign to a member of the MIR Team that is also on the Security Team (there is usually at least one). 0. While qt5webkit is in main, [[https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/1|it is temporary]] 0. Now that [[http://www.chriscoulson.me.uk/blog/?p=196|oxide-qt]] is in main, all software needing a webengine should be ported to work with the [[https://launchpad.net/ubuntu/+spec/client-1308-oxide|oxide bindings for the chromium content API]]. Application authors are encouraged to use !UbuntuWebView, but may also use Oxide directly. === Common blockers === * Does it FTBFS currently? * Does it have a test suite? Make sure it's being run and will fail the build upon error. * Does it have a team bug subscriber? (poke bdmurray once a team signs on, so that he can update the [[http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html|master list]] in [[http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/package-subscribers#L107|ubuntu-archive-tools]]) * Is the code translatable (if user visible)? * If it's a Python package, does it use dh_python? * If it's a Python package going on the desktop CD, will it pull in Python 2? === Packaging red flags === * Does Ubuntu carry a delta? * If it's a library, does it either have a symbols file or use an empty argument to dh_makeshlibs -V? (pass such a patch on to Debian, but don't block on it). Note that for C++, see [[DailyRelease/FAQ]] for a method to demangle C++ symbols files. * Does it have a watch file? * Is its update history slow or sporadic? * Is the current release packaged? * Will entering main make it harder for the people currently keeping it up to date? (i.e. are they only MOTUs?) * Lintian warnings * Is debian/rules a mess? Ideally it uses dh7 and overrides to make it as tiny as possible. * Does debian/control use `Built-Using`. This may may indicate static linking which should be discouraged (excepting golang, see below) * If it's a statically compiled golang package: * Does the package use dh-golang (if not, suggest dh-make-golang to create the package)? * Does debian/control use `Built-Using: ${misc:Built-Using}` for each non'-dev' binary package (importantly, golang-*-dev packages only ship source files so don't need Built-Using)? * Does the package follow [[http://pkg-go.alioth.debian.org/packaging.html|Debian Go packaging guidelines]]? === Upstream red flags === * Errors/warnings during the build * Incautious use of malloc/sprintf * Uses of sudo, gksu, pkexec, or LD_LIBRARY_PATH * Important bugs (crashers, etc) in Debian or Ubuntu * Dependency on webkit, qtwebkit, seed or libgoa-* * Embedded source copies (this happens frequently with Go upstreams) * If this is a scope for the Unity Dash, does it [[http://mhall119.com/2012/12/adding-privacy-setting-support-to-your-unity-lens/|honor the privacy settings]]? == Tools == * `check-mir` can be run from a checked out source and tell you which dependencies are in universe. * `seeded-in-ubuntu PACKAGE` can tell you whether and how a given PACKAGE is seeded * `reverse-depends` can tell you reverse source or binary depends, per component * The [[http://people.canonical.com/~ubuntu-archive/component-mismatches.svg|component mismatch map]] == Making Life Easier for Archive Team Members == To help prevent promotion of packages that cause component mismatches, we can do two things: 1. Run `check-mir` and make sure that all dependencies have a MIR. We don't want to be surprised by a dependency after a package is promoted. 1. List all distinct binary packages that should be promoted. Often a source package will have binary packages that aren't actually needed in main. Things like `-doc` or `-autopilot`. These can stay in universe, and it is a kindness to list only the packages we need for the archive team member that does the promotion. == Bug Lists == * [[https://bugs.launchpad.net/~ubuntu-mir|All MIR bugs]] * [[https://bugs.launchpad.net/~ubuntu-mir/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE|All open MIR bugs]] * [[https://bugs.launchpad.net/~ubuntu-mir/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none|All open unclaimed MIR bugs]] ---- CategoryUbuntuTeams |
#REDIRECT MainInclusionProcess |
MIRTeam (last edited 2020-03-24 15:53:06 by paelzer)