[MIR] libhandy

Doing the usual MIR checks I found most of them to be good:
- Duplication: it is actually deduplicating the embedded copies
- no lintian complains about packaging
- no functional bugs in Debian / Ubuntu yet (not used that much thou)
- Upstream is at and LGTM
- no embedded other libs
- no static linking
- d/rules and d/control are very clean
- meson build seems straight forward
- hardning=+all is in place
- runs (a few) build time self-tests
- you volunteered Ubuntu-Desktop as package subscriber
- no FTBFS currently nor in the recent history
- symbols are tracked for dh_makeshlibs
- packaging hs the most current release and updates ~monthly at least for now
- LD_LIBRARY_PATH only used in build
- no sudo (or similar) usage

Not perfect, but ok:
- autopkgtest only tests pkg-config and build against libhandy-dev
- yes it has no CVEs (yet), but it is too new to really know; a security evaluation is needed (probably ok thou since the siilar code is atm bundled in other packages in main)
- it has internationalization prepared (po/*) but only english so far
- usually a watch file would be nice but since upstream ~= Debian and doesn't release tarballs (but git tags) this doesn't really apply
- at least the -dev package depends on further universe packages e.g. libgladeui-2-6 do you intend (and ensure) to only pull libhandy-0.0 but no others to main?

Questions:
- the version number 0.0.7 is very unconvincing, does that mean it is still chaning API/ABI frequently - do you know if there is any major release planned that we should wait for?
- Debian bug 909075 holds it back from Debian and testing/integration there, should we wait until that is resolved (probably post buster) to move to it as well?
- (minor) build issue that could be resolved - do you want to contrib to Debian to even clean those?
  - "dpkg-gencontrol: warning: Depends field of package gir1.2-handy-0.0: substitution variable ${shlibs:Depends} used, but is not defined"
  - the docs might be incomplete "warning: no link for ..."

It will be nice to get the answers to the questions above resolved before completion, but IMHO we can already assign this to security for their review to appear on their queue.

[1]: https://source.puri.sm/Librem5/libhandy
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909075

I fixed the build issues you pointed out in Debian and Ubuntu now.

As I said, the Ubuntu Desktop team doesn't need this package in main for 19.04.

We have decided we don't want the -dev package in main because we don't want glade, so I have made sure it's excluded from the automatic inclusion of -dev packages:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=d2beb8

https://source.puri.sm/Librem5/libhandy/wikis/home suggests they will have their 0.1.0 first "stable" release next month alongside GNOME 3.32. It's hoped that the Librem 5 smartphone will being shipping soon after that.

*will begin shipping*

I reviewed libhandy 0.0.10-1 as checked into eoan. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

libhandy is a library full of GTK widgets for mobile phones. The aim of
libhandy is to help with developing UI for mobile devices using GTK/GNOME.

- No CVE History:
- Build-Depends
  - debhelper-compat
  - dh-sequence-gir
  - gtk-doc-tools
  - libgirepository1.0-dev
  - libgladeui-dev
  - libglib2.0-doc
  - libgnome-desktop-3-dev
  - libgtk-3-doc
  - libgtk-3-dev
  - libxml2-utils
  - meson
  - pkg-config
  - valac
- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- No binaries in PATH
- No sudo fragments
- No udev rules
- Unit tests / autopkgtests
  - under tests/ there are quite a few tests available testing different
    widgets
  - autopkgtests passing on:
    https://autopkgtest.ubuntu.com/packages/libh/libhandy
    https://ci.debian.net/packages/libh/libhandy/
- No cron jobs
- Build logs:
  - Some compiler warnings:
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-action-row'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-arrows'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-combo-row'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-dialer'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-dialer-cycle-button'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-dialog'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-expander-row'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-header-bar'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-header-group'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-preferences-group'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-preferences-page'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-preferences-row'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-preferences-window'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-search-bar'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-squeezer'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-string-utf8'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-value-object'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-view-switcher'
WARNING: Use the 'pie' kwarg instead of passing '-fpie' manually to 'test-view-switcher-bar'
html/HdyViewSwitcher.html:135: warning: no link for: "PangoEllipsizeMode" -> (<span class="type">PangoEllipsizeMode</span>).
html/HdyViewSwitcher.html:543: warning: no link for: "PANGO-ELLIPSIZE-NONE:CAPS" -> (<code class="literal">PANGO_ELLIPSIZE_NONE</code>)

- No processes spawned
- Memory management
  - It looks safe
- No File IO
- No Logging
- No Environment variable usage
- No Use of privileged...

Thanks for the check Eduardo, I'm actually not sure the Desktop Team still drives this oO.
All mid/high prio issues of the MIR review got adressed as well.
In terms of the process it seems this would be ok to be promoted, given that no commit is made to trigger the component mismatch per [1] the state for this until that is done is "in progress".

[1]: https://wiki.ubuntu.com/MIRTeam#Process_states

gnome-calendar is now depending on it so we are going to promote

package subscriber is missing

desktop-package subscribed and package promotoed