[MIR] ubuntu-push
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| ubuntu-push (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Availability: ubuntu-push-client is in universe
Rationale: The client communicates with ubuntu-push-server, which enables push/pull functionality for a bunch of apps (e.g. gmail, dekko, etc).
Quality assurance:
After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading.
- This is currently possible-ish.
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.
- I don't know what this means, sorry.
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.
- There are several, e.g. cgo pointer checks have been disabled and multiple unit tests have been disable because they are too flaky.
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.
- https:/
- https:/
- Full list: https:/
The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
- Launchpad
The package should not deal with exotic hardware which we cannot support.
- N/A
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.
- There is a suite, and it is run at build.
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/
- I don't know what this means, sorry.
End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
- It is translated. Not many things are user facing in u-p-c.
End-user applications must ship a standard conformant desktop file.
- N/A
Dependencies:
All binary dependencies (including Recommends:) must be satisfiable 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)
- TBD
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.
- There are efforts to make the packaging easier, but it's ongoing.
Maintenance: The package must have an acceptable level of maintenance corresponding to its complexity:
All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact.
- I think phablet-team owns this now.
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
- N/A
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.
- Right now that's the bug reporter.
Background information:
The package descriptions should explain the general purpose and context of the package. Additional explanations/
If the package was renamed recently, or has a different upstream name, this needs to be explained in the MIR report.
- https:/
Security checks
Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:
- Need to query either John Lenton or Samuele Pedronis.
Check for security relevant binaries. If any are present, this requires a more in-depth security review.
- u-p-c should go through in-depth security review.
Executables which have the suid or sgid bit set.
- Not sure, how do I know?
Executables in /sbin, /usr/sbin.
- N/A
Packages which install services / daemons (/etc/init.d/*, /etc/init/*, /lib/systemd/
- u-p-c runs as a service
| Michael Terry (mterry) wrote | #1 |
| Changed in ubuntu-push (Ubuntu): | |
| status: | New → Incomplete |
| Jonas G. Drange (jonas-drange) wrote | #2 |
| Michael Terry (mterry) wrote | #3 |
| Changed in ubuntu-push (Ubuntu): | |
| status: | Incomplete → Fix Committed |
| Matthias Klose (doko) wrote | #4 |
| Changed in ubuntu-push (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| Steve Langasek (vorlon) wrote | #5 |
| Changed in ubuntu-push (Ubuntu): | |
| status: | Fix Released → Fix Committed |
| Steve Langasek (vorlon) wrote | #6 |
| Changed in ubuntu-push (Ubuntu): | |
| status: | Fix Committed → Fix Released |
Blockers:
- Needs a proper team LP bug subscriber.
Questions:
- acceptance and http13client tests are skipped during debuild. Why? Do the http tests actually try to hit the network, instead of setting up a mock http server?
- What's the story with bug 1475612, are we ftbfs in some cases?
Non blocking notes:
- There are a lot of warnings during test runs. Presumably ignorable, but it would be hard to notice something that wasn't ignorable among all the chaff.
- "DEB_BUILD_OPTIONS := nocheck" in debian/rules doesn't do anything, because the given override_
- "${misc:Depends}" should be added to ubuntu-
- This is an Ubuntu-centric package and we're not worried about being in sync with Debian, so I'm not going to block on this, but the -dev package name is wrong. According to Debian Go packaging guidelines [1], it should be golang-
- This will need a security look at some point before the LTS, but the security team doesn't want to block this MIR on that.
- You can't currently debuild twice in a row because the clean target doesn't properly clean signing-helper/. It might help if you changed the build override to run cmake into a special build dir and installed the signing helper from that dir in ubuntu-
[1] http://
Answers:
- You weren't sure about debconf. It's just a system that some packages use to ask a user to make a choice during package install (or upgrade). They are generally something we try to avoid, since it's a bad user experience. Most packages don't have them.
- You weren't sure about debian/watch. It's a file that some packages have that describe where upstream tarballs are. That way, a package developer can use "uscan" to see if there's a new update for the package. And so can automated tools. Mostly useful when you a packaging a separate upstream rather than like this package, where we are the upstream.