[MIR] wayland protocol package
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
wayland (Ubuntu) |
Fix Released
|
Medium
|
Didier Roche-Tolomelli |
Bug Description
Availability: wayland is in universe and buildable for i386, amd64, and armel. Not sure if it's relevant for armel but it builds fine. Omitted from powerpc for now.
Rationale:
1. wayland is now an (optional) build dependency of mesa, which we already support in main.
2. mesa + wayland provides 'wayland-egl'
3. wayland-demos requires wayland-egl as a build dependency.
4. wayland-demos provides an example wayland compositor and tools; we want to be able to provide this in universe for wayland experimenters.
5. In addition, Canonical has indicated interest in adding wayland support to compiz/unity. The wayland package will be needed by those packages for the protocol library.
Security:
1. No security issues have been reported against this package.
2. No executables have the suid or sgid bit set.
3. No executables in /sbin, /usr/sbin.
4. No daemons (/etc/init.d/*)
5. No privileged ports (ports < 1024).
6. No add-ons or plugins to security-sensitive software (filters, scanners, UI skins, etc)
Quality assurance:
1. No configuration is required
2. No debconf questions
3. Upstream is attentive to bug reports and patches
4. All bugs reported to Ubuntu have been resolved. There are no open bug reports in Debian.
5. No test suite is included in the package
6. A debian/watch file is provided, however upstream has not produced releases. However there is a gentarball rule for producing the source tar file.
Bug trackers:
Ubuntu - (0 bugs) https:/
Debian - (0 bugs) http://
Upstream - Wayland doesn't have a bugtracker itself - bugs are discussed on irc or the mailing list:
http://
UI standards: N/A
Dependencies: All required dependencies are in main
Standards compliance: The package meets the FHS and Debian Policy standards.
Maintenance: For now this package will be maintained by the Ubuntu-X team. It is not anticipated much maintenance will be required of this package beyond what Debian already does, and syncing/merging their changes in.
Background information:
In natty we shipped a single wayland package in universe; for oneiric this is split into two pieces - wayland and wayland-demos. The wayland package defines the protocol and provides headers and libraries and is the piece that we'll want to have in main. The wayland-demos package includes wayland-enabled clients and an example compositor/window manager; it will be nice to have in universe for experimenters.
summary: |
- Main Inclusion Request for wayland protocol package + [MIR] wayland protocol package |
description: | updated |
tags: | added: ppc |
Changed in wayland (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
status: | Confirmed → New |
Changed in wayland (Ubuntu): | |
assignee: | nobody → Didier Roche (didrocks) |
* debian/copyright: wayland- hash.c: MIT/X11
- wayland/scanner.c: GPL (v2 or later)
-> this one is indeed listed but there is no COPYING or LICENSE file of GPLv2 upstream, which should be mandatory to release the upstream package (ok, they never released a tarball yet, but it's not too late to fix that!)
- wayland/
-> this is listed as well in debian/copyright, but the Licence: should be set to "MIT"
- for the remaining pieces, I don't know what to put for empty Licence: I would just either skip the section or put "unkown" or "public domain"
* debian/rules: dh_auto_ install:
dh_auto_ install --destdir= debian/ tmp
more a question than anything else, I'm surprised about this:
# Install in debian/tmp to retain control through dh_install:
override_
is it really needed? Is it the fact to change the builddir which affects the destdir?
* debian/ wayland. lintian- overrides:
I guess this override should be on libwayland0 to have some effect (it doesn't right now)
* debian/ libwayland- dev.install wayland- scanner
# Tool to build various other packages:
usr/bin/
wayland-scanner.mk seems to indicate (and confirmed by RAOF) that the scanner is used to generate the header files from the xml protocol.
Consequently, I'm wondering why we need to ship it in the -dev package, as we don't ship the xml file for the protocole but directly the generated header?
All the rest of the packaging is really nice, usage of --fail-missing, ensuring some control over the instability of the ABI, autogenerated symbol files and such :)
Please reopen once the copyright is fixed (and ping me on IRC) and those quesstion answered! Thanks a lot : )