I'm closing this bug since it enables a fairly obscure feature. flite
isn't well maintained currently. I'm told spiel is better but it's not
packaged yet.
I was told Fedora enables speech synthesis in webkitgtk for the same
reason Debian does: because flite is packaged. However in GNOME OS,
speech synthesis is disabled in webkitgtk because nobody "packaged" it
there.
** Changed in: flite (Ubuntu)
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to flite in Ubuntu.
https://bugs.launchpad.net/bugs/2096940
Title:
[MIR] flite
Status in flite package in Ubuntu:
Won't Fix
Bug description:
Setting as incomplete while I gather more information and finish the
paperwork here.
[Availability]
The package flite is already in Ubuntu universe.
The package flite build for the architectures it is designed to work
on.
It currently builds and works for architectures: all Ubuntu
architectures (including i386)
Link to package https://launchpad.net/ubuntu/+source/flite
[Rationale]
- The package flite is required in Ubuntu main to enable speech synthesis in
webkit2gtk as was done in Debian.
https://mdn.github.io/dom-examples/web-speech-api/speak-easy-
synthesis/
https://caniuse.com/speech-synthesis
In my testing, this feature works in the Firefox snap but not the
Chromium snap (I'll follow up there). This is a request for it to work
in webkit2gtk which is used by the Epiphany browser.
gstreamer's "bad" plugins also have a plugin that uses flite. We may
eventually try to get part of "bad" into main.
- The package flite is a new runtime dependency of package webkit2gtk
that we already support
- There is no other/better way to solve this that is already in main or
should go universe->main instead of this.
webkit2gtk's speech synthesis feature works with either flite or libspiel but
libspiel is not packaged in Debian or Ubuntu.
- It would be great and useful to community/processes to have the
package flite in Ubuntu main, but there is no definitive deadline.
[Security]
https://cve.mitre.org/cve/search_cve_list.html
- check OSS security mailing list (feed into search engine
site:www.openwall.com/lists/oss-security flite')
- Ubuntu CVE Tracker
https://ubuntu.com/security/cve?package=flite
- Debian Security Tracker
https://security-tracker.debian.org/tracker/source-package/flite
- Had 1 security issues in the past
+ https://ubuntu.com/security/CVE-2014-0027
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
TODO: - Security has been kept in mind and common isolation/risk-mitigation
TODO: patterns are in place utilizing the following features:
TODO: TBD (add details and links/examples about things like dropping
TODO: permissions, using temporary environments, restricted users/groups,
TODO: seccomp, systemd isolation features, apparmor, ...)
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu/Upstream and does not have
too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/flite/
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=flite
- Upstream's bug tracker https://github.com/festvox/flite/issues
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
- The package does not run a test at build time because TBD
RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
TODO-A: - The package runs an autopkgtest, and is currently passing on
TODO-A: this TBD list of architectures, link to test logs TBD
TODO-B: - The package does not run an autopkgtest because TBD
RULE: - existing but failing tests that shall be handled as "ok to fail"
RULE: need to be explained along the test logs below
TODO-A: - The package does have not failing autopkgtests right now
TODO-B: - The package does have failing autopkgtests tests right now, but
since
TODO-B: they always failed they are handled as "ignored failure", this is
TODO-B: ok because TBD
RULE: - If no build tests nor autopkgtests are included, and/or if the package
RULE: requires specific hardware to perform testing, the subscribed team
RULE: must provide a written test plan in a comment to the MIR bug, and
RULE: commit to running that test either at each upload of the package or
RULE: at least once each release cycle. In the comment to the MIR bug,
RULE: please link to the codebase of these tests (scripts or doc of manual
RULE: steps) and attach a full log of these test runs. This is meant to
RULE: assess their validity (e.g. not just superficial).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - TBD
RULE: - In some cases a solution that is about to be promoted consists of
RULE: several very small libraries and one actual application uniting them
RULE: to achieve something useful. This is rather common in the go/rust
space.
RULE: In that case often these micro-libs on their own can and should only
RULE: provide low level unit-tests. But more complex autopkgtests make no
RULE: sense on that level. Therefore in those cases one might want to test
on
RULE: the solution level.
RULE: - Process wise MIR-requesting teams can ask (on the bug) for this
RULE: special case to apply for a given case, which reduces the test
RULE: constraints on the micro libraries but in return increases the
RULE: requirements for the test of the actual app/solution.
RULE: - Since this might promote micro-lib packages to main with less than
RULE: the common level of QA any further MIRed program using them will
have
RULE: to provide the same amount of increased testing.
TODO: - This package is minimal and will be tested in a more wide reaching
TODO: solution context TBD, details about this testing are here TBD
[Quality assurance - packaging]
RULE: - The package uses a debian/watch file whenever possible. In cases where
RULE: this is not possible (e.g. native packages), the package should either
RULE: provide a debian/README.source file or a debian/watch file (with
RULE: comments only) providing clear instructions on how to generate the
RULE: source tar file.
TODO-A: - debian/watch is present and works
TODO-B: - debian/watch is not present, instead it has TBD
TODO-C: - debian/watch is not present because it is a native package
- debian/control defines a correct Maintainer field
RULE: - It is often useful to run `lintian --pedantic` on the package to spot
RULE: the most common packaging issues in advance
RULE: - Non-obvious or non-properly commented lintian overrides should be
RULE: explained
TODO: - This package does not yield massive lintian Warnings, Errors
TODO: - Please link to a recent build log of the package <TBD>
TODO: - Please attach the full output you have got from
TODO: `lintian --pedantic` as an extra post to this bug.
TODO-A: - Lintian overrides are not present
TODO-B: - Lintian overrides are present, but ok because TBD
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions
- Packaging and build is easy, link to debian/rules
https://salsa.debian.org/a11y-team/flite/-/blob/master/debian/rules
[UI standards]
- Application is not end-user facing (does not need translation or .desktop)
The package description says it supports English and Indic languages.
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
TODO-A: - The owning team will be TBD and I have their acknowledgement for
TODO-A: that commitment
TODO-B: - I Suggest the owning team to be TBD
TODO-A: - The future owning team is already subscribed to the package
TODO-B: - The future owning team is not yet subscribed, but will subscribe to
TODO-B: the package before promotion
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built within the last 3 months in the archive
- Build link on launchpad: https://launchpad.net/ubuntu/+source/flite/2.2-7
[Background information]
The Package description explains the package well
Upstream Name is flite
Links to upstream project
http://cmuflite.org/
https://github.com/festvox/flite
flite was in Ubuntu main from Ubuntu 6.06 LTS until it was no longer
required for Build-Depends to be in main. The paperwork was simpler
then!
https://wiki.ubuntu.com/MainInclusionReportFlite
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flite/+bug/2096940/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
