[MIR] UNR packages

[Steve Kowalik]

 This is the set of packages contained in UNR that aren't in main that
need to be looked at to be promoted to main. MIRs will be forthcoming.

 affects ubuntu/cellwriter
 affects ubuntu/cheese
 affects ubuntu/clutter
 affects ubuntu/clutter-gtk
 affects ubuntu/desktop-switcher
 affects ubuntu/fbreader
 affects ubuntu/go-home-applet
 affects ubuntu/human-netbook-theme
 affects ubuntu/libfakekey
 affects ubuntu/liblinebreak
 affects ubuntu/maximus
 affects ubuntu/netbook-launcher
 affects ubuntu/ubuntu-netbook-remix-default-settings
 affects ubuntu/webfav
 affects ubuntu/window-picker-applet
 affects ubuntu/xautomation
 affects ubuntu/xf86-input-evtouch

[Steve Kowalik (stevenk)]

Clutter:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/c/clutter; available for all architectures except for armel -- I suspect the armel build failure could be corrected with a no-change upload.
2. Rationale:
    * Dependency of netbook-launcher
3. Security:
    * No CVE entries: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=clutter
    * Secunia history: http://secunia.com/search/?search=clutter
    * No binaries, only shared libraries.
    * No network activity.
    * No processing of binary data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box in all situations.
    * No debconfage.
    * No Debian bugs.
    * Maintaince in Debian is calm, we tend to package it ourselves.
    * Upstream is vigorous.
    * Could not locate an upstream bug tracker.
    * This package deals with 3D acceleration, so works better with a card that deals with that.
    * A test suite is present, but doesn't look to run during the build -- may require graphics to do so.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? It's a library.
6. Standards compliance:
    * Complies with Debian Policy and the FHS.
    * Bog-standard CDBS with debhelper, no patch system or oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need? Upstream are very responsive, so updating to the latest version is nice, but that isn't much work.
    * Who is responsible for monitoring the quality of this package and fixing its bugs? The mobile team.
9. Background information:
    * From what I can see, upstream call it clutter, and it hasn't had any other names.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Yes.

[Steve Kowalik (stevenk)]

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/c/clutter-gtk; available for all architectures.
2. Rationale:
    * Dependency of netbook-launcher
3. Security:
    * No CVE entries: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=clutter-gtk
    * Secunia history: http://secunia.com/search/?search=clutter-gtk
    * No binaries, only shared libraries.
    * No network activity.
    * No processing of binary data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box in all situations.
    * No debconfage.
    * No Debian bugs.
    * Maintaince in Debian is calm.
    * Upstream is vigorous.
    * Could not locate an upstream bug tracker.
    * This package deals with 3D acceleration, so works better with a card that deals with that.
    * No test suite that I could see.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? It's a library.
6. Standards compliance:
    * Complies with Debian Policy and the FHS.
    * Bog-standard CDBS with debhelper, no patch system or oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main, except for clutter.
8. Maintenance:
    * How much maintenance is this package likely to need? Upstream are very responsive, so updating to the latest version is nice, but that isn't much work.
    * Who is responsible for monitoring the quality of this package and fixing its bugs? The mobile team.
9. Background information:
    * From what I can see, upstream call it clutter-gtk, and it hasn't had any other names.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Yes.

[Steve Kowalik (stevenk)]

MIR for cheese:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/c/cheese; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries, the only entry matches on cheesetracker, a different source.
    * No matches in Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, in both cases.
    * No network activity.
    * Does not seem to process binary or structed data directly.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * No relevant Debian bugs.
    * Maintenance in Debian is irrelevant, we maintain the package ourselves.
    * Upstream is vigorous.
    * Upstream bug tracker: (mention any particularly relevant or critical)
    * Hardware: This package deals with webcams.
    * There doesn't look to be a testsuite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? Yes
6. Standards compliance:
    * Compiles with both the FHS and Debian Policy.
    * Bog-standard CDBS + debhelper with simple-patchsys. No oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not a lot, it gets updated to a new upstream fairly frequently.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The desktop team.
9. Background information:
    * What do upstream call this software ? Has it had different names in the past ? cheese. Doesn't seem to have had any other names.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Yes.

[Steve Kowalik (stevenk)]

MIR for desktop-switcher:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/d/desktop-switcher; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, on both counts.
    * No network stuff.
    * No handling of binary of structured data directly.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package does not exist in Debian.
    * Upstream is calm.
    * Upstream bug tracker is Launchpad: https://bugs.launchpad.net/desktop-switcher
    * No special hardware requirements.
    * No test suite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? No.
6. Standards compliance:
    * Compiles to the FHS and Debian Policy.
    * debhelper v7 with no patch system and no oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Very little, it's a simple package.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call this desktop-switcher, and it hasn't had different names.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Yes.

[Steve Kowalik (stevenk)]

MIR for go-home-applet:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/g/go-home-applet; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix.
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, on both counts.
    * No network activity.
    * No processing of binary or structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package isn't in Debian.
    * Upstream is calm.
    * Upstream bug tracker: https://bugs.launchpad.net/go-home-applet
    * No hardware requirements.
    * No test suite that I could see.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? No.
6. Standards compliance:
    * Compiles to the FHS and Debian Policy.
    * CDBS + debhelper, simple-patchsys, no oddities, handwave.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Likely none, or not very much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call it go-home-applet.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Yes.

[Steve Kowalik (stevenk)]

MIR for human-netbook-theme:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/h/human-netbook-theme; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * No binaries.
    * No processing of binary or structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package is not in Debian.
    * Upstream is calm.
    * Upstream bug tracker: https://bugs.launchpad.net/human-netbook-theme
    * No hardware requirements.
    * No test-suite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? No
6. Standards compliance:
    * Complies with the FHS and Debian Policy.
    * CDBS + debhelper, no patch system, no oddities.
7. Dependencies:
    * Build-Depends and Depends are all in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call this software human-netbook-theme, and it hasn't had any other names in the past.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? No graphical applications in the package.

[Steve Kowalik (stevenk)]

libfakekey has already seen main (thanks to bug 149275), perhaps it could be re-promoted, maximus requires it.

[Steve Kowalik (stevenk)]

MIR for window-picker-applet:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/w/window-picker-applet; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix.
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, on both counts.
    * No network activity.
    * No processing of binary or structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package isn't in Debian.
    * Upstream is calm.
    * Upstream bug tracker: https://bugs.launchpad.net/window-picker-applet
    * No hardware requirements.
    * No test suite that I could see.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? No.
6. Standards compliance:
    * Compiles to the FHS and Debian Policy.
    * CDBS + debhelper, no oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Likely none, or not very much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call it window-picker-applet.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Yes.

[Steve Kowalik (stevenk)]

MIR for maximus:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/m/maximus; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No relevant CVE entries: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=maximus
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, on both counts.
    * No network activity.
    * No processing of binary or structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package is not in Debian.
    * Upstream is calm.
    * Upstream bug tracker: https://bugs.launchpad.net/maximus
    * No hardware requirements.
    * No test suite that I could see.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? No user-visible strings.
    * Package with translatable strings builds a PO template during package build ? See previous.
    * End-user applications ship a desktop file ? It has an autostart desktop file.
6. Standards compliance:
    * Complies with the FHS and Debian Policy.
    * CDBS + debhelper + simple-patchsys, no oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main, with the exception of libfakekey.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call this program maximus, and it hasn't had any different names.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? It isn't a graphical application.

[Martin Pitt (pitti)]

unr-meta is trivial, approved.

[Martin Pitt (pitti)]

ubuntu-netbook-remix-default-settings is trivial, approved.

[Martin Pitt (pitti)]

libfakekey approved via bug 149275

[Steve Kowalik (stevenk)]

MIR for webfav:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/w/webfav; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ?
    * No network activity directly -- it stores favourites for firefox.
    * Does not directly process binary or structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package is not in Debian.
    * Upstream is calm.
    * Upstream bug tracker: https://bugs.launchpad.net/webfav
    * No hardware requirements.
    * No test suite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? No, the XPI system.
    * Package with translatable strings builds a PO template during package build ? No, see previous.
    * End-user applications ship a desktop file ? No.
6. Standards compliance:
    * Complies with FHS and Debian Policy.
    * Mozilla-devscripts + CDBS, no patch system. A little bit odd, but that's Mozilla for you.
7. Dependencies:
    * All Build-Depends are in main, except it Depends on netbook-launcher, which is currently in universe.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream calls this software webfav.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? Not a graphical application.

[Martin Pitt (pitti)]

desktop-switcher looks fine, approved.

[Martin Pitt (pitti)]

window-picker-applet is fine, approved.

[Martin Pitt (pitti)]

Whoops, desktop-switcher uses dh_auto, not cdbs, and doesn't do the gnome.mk magic. You need to fix debian/rules to build a .pot file during package build and add X-GNOME-Gettext-Domain: to the .desktop files.

[Steve Kowalik (stevenk)]

As proved to pitti on IRC, desktop-switcher already does both of those.

[Martin Pitt (pitti)]

desktop-switcher approved.

[Alexander Sack (asac)]

webfav MIR approved.

[David Planella (dpm)]

Regarding webfav

> 10. Internationalization:
> * Are graphical applications translatable? Do they support gettext? Not a graphical application.

It is translatable (and if I'm not mistaken the strings are visible in the UI), but it does not use gettext.

The format it uses is the same one as Firefox: a .dtd XML file plus a .properties Java/Js properties definitions file.

The only difference is in the packaging: while in Firefox there is a separate ll.xpi (where ll is the language code) archive containing the translations for each locale, webfav has all translations embedded in the package itself.

This is important when importing the translations into Launchpad and when exporting them in language packs: the way it works in Firefox is the following -> first, the ll.xpi individual translations are imported into Launchpad (which supports native xpi imports) independently from the package. When exporting them to be released in the language packs, Launchpad does not support native exports, so they are available only as an intermediate format called XPIPO. In order to convert them back to .dtd and .properties, which is what ultimately will be released in the language packs, po2xpi (https://code.launchpad.net/~mozillateam/rosetta/po2xpi) must be used.

Now that webfav is going to be promoted into main and its translations released in language packs, this should probably be taken care of in the package.

[Alexander Sack (asac)]

> Now that webfav is going to be promoted into main and its translations released in language packs, this should
> probably be taken care of in the package.

From what I understood this was being worked on. But yeah, could you please file a bug on this so this doesn't fall off the radar, David?

[David Planella (dpm)]

El dt 07 de 07 de 2009 a les 09:53 +0000, en/na Alexander Sack va
escriure:
> > Now that webfav is going to be promoted into main and its translations released in language packs, this should
> > probably be taken care of in the package.
>
> >From what I understood this was being worked on. But yeah, could you
> please file a bug on this so this doesn't fall off the radar, David?
>

Yes, done. Filed bug 396492 for that.

[Alexander Sack (asac)]

go-home-applet MIR approved.

[Alexander Sack (asac)]

maximus approved.

[Steve Kowalik (stevenk)]

MIR for netbook-launcher:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/n/netbook-launcher; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, neither.
    * No networking.
    * No direct processing of binary of structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * Package is not in Debian.
    * Upstream is vigorour.
    * Upstream bug tracker: https://bugs.launchpad.net/netbook-remix-launcher
    * No special hardware requirements.
    * No test suite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Yes
    * Package with translatable strings builds a PO template during package build ? Yes
    * End-user applications ship a desktop file ? It ships an autostart desktop file.
6. Standards compliance:
    * Compiles with the FHS and Debian Policy.
    * CDBS + debhelper, simple-patchsys, no oddness.
7. Dependencies:
    * All Depends and Build-Depends, with the exception of clutter and clutter-gtk are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call this either netbook-launcher, or netbook-remix-launcher.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext?

[Steve Kowalik (stevenk)]

MIR for xautomation:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/x/xautomation; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? No, on both counts.
    * Only if X network traffic doesn't count, but that's on the part of the X server itself.
    * No processing of binary or structured data.
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * No relevant Debian bugs
    * Maintenance in Debian is calm.
    * Upstream is calm.
    * No upstream bug tracker.
    * No hardware requirements.
    * No test-suite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? No.
    * Package with translatable strings builds a PO template during package build ? No.
    * End-user applications ship a desktop file ? No.
6. Standards compliance:
    * Compiles with the FHS and Debian Policy.
    * Standard debhelper, no patch system, or oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not much.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call this software 'xautomation'.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? No graphical applications.

[Steve Kowalik (stevenk)]

MIR for liblinebreak:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/libl/liblinebreak; available for all supported architectures
2. Rationale:
    * Dependency of fbreader, which is seeded by ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ? Only shared libraries.
    * No network activity.
    * Processes Unicode (structured, I guess)
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * No relevant Debian bugs.
    * Maintenance in Debian is calm.
    * Upstream is calm.
    * Upstream bug tracker: http://sourceforge.net/tracker/?group_id=204455&atid=989680; none relevant.
    * No hardware requirements.
    * No testsuite.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? No.
    * Package with translatable strings builds a PO template during package build ? No
    * End-user applications ship a desktop file ? No, it's a library.
6. Standards compliance:
    * Compiles with FHS and Debian Policy.
    * debhelper v7, no patch system or oddities.
7. Dependencies:
    * All Build-Depends and Depends are in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not very.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call it liblinebreak, but is under the vim gadgets project.
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? It's a shared library.

[Alexander Sack (asac)]

xautomation MIR approved,

Sidenote: "No processing of binary or structured data" seems wrong to me as there are image processing binaries inside this package.
Also I would love if MIR rationales would be a bit more verbose, e.g. just "required for X" isn't that helpful; however, "required for X to do Y and we couldn't use Z1, Z2, etc. because of R1, R2, etc." is extremely helpful. Thanks!

[Steve Kowalik (stevenk)]

As it turns out, UNR does not require xautomation, so I'll be unseeding it, and I'll set the task to Invalid. Alexander, sorry for wasting your time. :-(

[Steve Kowalik (stevenk)]

MIR for fbreader:

1. Availability: http://archive.ubuntu.com/ubuntu/pool/universe/f/fbreader; available for all supported architectures
2. Rationale:
    * Dependency of ubuntu-netbook-remix
3. Security:
    * No CVE entries.
    * No Secunia history.
    * Any binaries running as root or suid/sgid ? Any daemons ?
    * No network activity.
    * It directly processes structured data (random ebook formats)
    * No source code review.
4. Quality assurance:
    * Package works out of the box.
    * No debconfage.
    * No relevant Debian bugs.
    * Maintenance in Debian is calm.
    * Upstream is calm.
    * Upstream bug tracker: (mention any particularly relevant or critical)
    * No particular hardware requirements.
    * No test suite that I could see.
5. UI standards:
    * User-visible strings are internationalized using standard gettext system ? Does not seem to use gettext.
    * Package with translatable strings builds a PO template during package build ? See previous.
    * End-user applications ship a desktop file ? Yes, it ships a desktop file.
6. Standards compliance:
    * Complies with FHS and Debian Policy.
    * debhelper v7 with quilt and no oddities.
7. Dependencies:
    * liblinebreak is in universe, but has an MIR filed.
    * libosso is also in universe, but has already seen main thanks to bug 149275.
    * Everything else is in main.
8. Maintenance:
    * How much maintenance is this package likely to need ? Not much, both upstreams are responsive.
    * Who is responsible for monitoring the quality of this package and fixing its bugs ? Are they Ubuntu or Debian developers ? The mobile team.
9. Background information:
    * The general purpose and context of the package should be clear from the package's debian/control file. If it isn't then please explain.
    * Upstream call this software 'fbreader'
10. Internationalization:
    * Are graphical applications translatable? Do they support gettext? See point 5.

[Steve Kowalik (stevenk)]

Further to fbreader MIR:

Upstream bug tracker is at http://www.fbreader.org/mantis and there no relevant bugs that I could find.

[Steve Kowalik (stevenk)]

Even further to the fbreader MIR:

Any binaries running as root or suid/sgid ? Any daemons ? No, in either case.

[David Planella (dpm)]

And more info on the fbreader MIR, regarding internationalization:

> 5. UI standards:
> * User-visible strings are internationalized using standard gettext system ? Does not seem to use gettext.
> * Package with translatable strings builds a PO template during package build ? See previous.
> * End-user applications ship a desktop file ? Yes, it ships a desktop file.

> 10. Internationalization:
> * Are graphical applications translatable? Do they support gettext? See point 5.

Localization support is not yet completely implemented upstream. The application does not use gettext, but the UI can be localized through XML files. "Interface localization" seems to be one of their listed requests at http://www.fbreader.org/more/requests.php, but there's no roadmap defined for implementation nor it is described whether they are going to use gettext.

That effectively means that in the current state fbreader would not be translatable in Ubuntu and its localized interface would only available in English, Finnish, French, Russian, Swedish and Ukrainian (for the official distribution). Additionally, there are more localizations available for Arabic, Czech, Indonesian and Italian.

If fbreader were to be included in main, Ubuntu Translators should be consulted about it.

More information here: http://www.fbreader.org/docs/i18n.php

[Martin Pitt (pitti)]

liblinebreak: clean package, small; code is mostly tables, and actual algorithms are cautiously written (no dynamic allocation, no sprintf, uses strncmp(), etc.). Approved.

[Martin Pitt (pitti)]

netbook-launcher: clean packaging, in-house development, proper i18n/pot building. Approved.

[Martin Pitt (pitti)]

fbreader review:
 - package comes with its own GUI library, which apparently isn't used anywhere else
 - package pulls in qt3, which the KDE team tries to get rid of; is it possible to just build a qt4 variant?
 - package b-deps on libhildon-1-dev, libosso-dev; I thought this stack was pretty much obsolete now? Can these be dropped, so that zlibrary just builds gtk/qt4/text backends?
 - the missing gettext support is a bit of a bummer; OTOH, ./src/fbreader/FBReaderActionCode.cpp is the central location for all strings, so wrapping those into _() and adding some standard intltool build system stuff doesn't sound too hard. Can this be proposed and contributed upstream? The XML files should be converted to standard po files, and then gotten rid of.

[Loïc Minier (lool)]

Cheese DOES process video data, from the webcam, but that's ok.

I think the scrollkeeper build-dep should be replaced by rarian or rarian-compat.

The man page should be installed via debian/cheese{,-hildon}.manpages.

src/gst-audio-play.h and src/gst-audio-play.c are LGPL not GPL.

Build-deps on libgconf2-4 instead of libgconf2-dev (gconf headers are used in src/cheese-gconf.c for instance).

The libhal-dev bdep might become an issue in the future, but we can worry about that later.

I also wonder whether a capplet should be suggested, but that's ok.

Could you please fix the copyright and bdep issues? This should be enough. The manpages seem easy to fix too, but aren't required.

Perhaps we should also make the desktop team aware of the proposed new responsibility for this package; Martin is this ok?

[Loïc Minier (lool)]

Cheese: the upstream bug tracker mentions some crashes with particular webcams, but I think that's ok. http://bugzilla.gnome.org/buglist.cgi?product=cheese&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_severity=blocker&bug_severity=critical&bug_severity=major

[Loïc Minier (lool)]

Cheese: manpages, licensing and libgconf2-dev issues were fixed in Debian; I fixed the scrollkeeper bdep there. I recommend merging a later Debian version.

[Loïc Minier (lool)]

Clutter: misc small packaging tweaks which are not required and which I did in Debian:
  * Downgrade pkg-config dep to a recommends.
  * Update download URL in copyright.
  * Use LDFLAGS/CFLAGS vars directly to avoid overriding them completely; bdep
    on cdbs >= 0.4.41.
  * Let libclutter-0.8-dev dep on ${shlibs:Depends}.
  * Bdep on libpango1.0-dev (>= 1.18) and libglib2.0-dev (>= 2.14)
    explicitely.
there's a lintian warning due to lack of ${misc:Depends} which is fixed in Debian.

Clutter currently fails to build on armel.

Upstream bug tracker seems to still be OH bugzilla:
http://bugzilla.o-hand.com/buglist.cgi?product=Clutter&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major

Should the Canonical Mobile team or the Ubuntu UNR team be in charge of this package?

[Loïc Minier (lool)]

Clutter-Gtk: I did these packaging changes in Debian:
  * Downgrade pkg-config dep to a recommends.
  * Let libclutter-gtk-0.8-dev depend on ${shlibs:Depends}.
  * Update download URL in copyright.
  * Bump shlibs to >= 0.8.2 as this release added API.
  * Use LDFLAGS var directly to avoid overriding them completely; bdep on cdbs
    >= 0.4.41.
  * Bdep on pkg-config for PKG_CHECK_MODULES().
  * Bump libclutter-0.8-dev bdep and dep to >= 0.8.7 to match configure.ac.
so nothing really critical

Licensing/copyright were ok.

clutter-gtk obviously failed to build on armel as well.

Hmm contrarily to your claims, clutter-gtk doesn't build a .pot; probably uses the wrong CDBS include, please fix this.

[Loïc Minier (lool)]

Please make clutter build a .pot.

[Loïc Minier (lool)]

human-netbook-theme: looks good, approved.

[Steve Kowalik (stevenk)]

cheese 2.27.3-0ubuntu2 uploaded, which should address all concerns.

[Steve Kowalik (stevenk)]

clutter and clutter-gtk uploaded to sort out the .pot file building issue.

[Steve Kowalik (stevenk)]

fbreader also uploaded, sorting out everything aside from the i18n.

[Loïc Minier (lool)]

Ack on clutter

[Loïc Minier (lool)]

Ack on clutter-gtk which still doesn't build a pot file BTW, but it's because there's none to be built. :-)

[Loïc Minier (lool)]

Ack on Cheese; note that Debian used debian/manpages (more elegant IMO; would have been nice to merge!)

[Martin Pitt (pitti)]

fbreader packaging/review is ok now.

Personally I'd consider the lack of sensible translatability a showstopper, but I don't want to impose that judgement on the mobile team. If your team decides that it is ok to ship with poorly/nontranslated fbreader (or you plan to fix it later), please go ahead. Reassigning to Loic for this decision.

[Loïc Minier (lool)]

I agree that lack of i18n in fbreader is a blocker; I'm willing to promote it if we have a path to deliver i18n before karmic releases, but wouldn't want to recommend this app to non-English speakers until we do.

[David Planella (dpm)]

Just for the record, as talked on IRC, I contacted upstream about contributing changes to provide gettext support:

1) Code changes

• Add gettext support in the code
• Replace the string ID's in the code by the English strings
• Wrap all those strings in _() so they can be extracted by xgettext

2) Migration changes

• Write a script to do a one-time extraction of the existing
translations in the xml files under the data/resources directory and put
them into separate gettext .po files. With this we would ensure that the
existing translations are used.

Something to have into account are their contribution guidelines -> http://www.fbreader.org/docs/contributions.php

[Loïc Minier (lool)]

Thanks David; is there an upstream bug about this? What did upstream think about switching to gettext? Is someone on the Ubuntu side of things picking this up already?

[Kyle Nitzsche (knitzsche)]

There are a couple other aspects to i18nizing fbreader.
 * On launch, fbreader displays an e-book that is fbreader's help/introduction. This is in English even if the user has switched the user interface to another language. This could be translated and code could be written to display the version that's the best match with the current locale.
 * The UI interface contains widgets for setting the language. This could/should be removed and be replaced with normal automatic locale detection.

[Steve Kowalik (stevenk)]

It has been decided that fbreader is not being considered at this time, so I've unseeded it.

[Steve Kowalik (stevenk)]

Everything has been promoted.

[Steve Kowalik (stevenk)]

Due to liblinebreak appearing in component-overrides, and the fact that only fbreader required it, which didn't get promoted anyway, I've demoted it back to universe.