[MIR] libertine

[Christopher Townsend]

[Availability]
Currently in Universe

[Rationale]
It is a dependency of ubuntu-app-launch which is being promoted to main.

[Security]
No vulnerabilities are known.

[Quality assurance]
Quality is good and is used on the phone/tablet and tested by Ubuntu QA.

[Dependencies]
All necessary dependencies are in main.

[Standards compliance]
Believed to meet standards compliance.

[Maintenance]
In active development and maintenance.

[Background information]
This package provides a set of tools and libraries to support running X applications on Unity 8.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Terry (mterry)]

- Needs a team bug subscriber (~desktop-packages maybe? Who owns libertine?)

- I'm getting several test failures in test_libertine when building in a yakkety pbuilder. Do you see these? Errors like "RuntimeError: Container_init:lxc.c:454: error during init for container 'test-id-2'."

- Several important looking bugs, but I know that libertine is being rapidly developed and is expected to have warts right now.

Otherwise seems fine and well maintained.

[Christopher Townsend (townsend)]

Hi Michael,

Thanks for looking at this.

I'm not exactly sure what you mean by team bug subscriber. Is this something that is needed in the debian/control file or something for this bug or something else? The libertine-team is the official team for libertine.

I am seeing this error too and looks to be some issue w/ lxc in yakkety. I will need to follow up with the lxc maintainers.

[Christopher Townsend (townsend)]

Looking more into the test issue, I can recreate it in a Xenial pbuilder as well. I'm wondering if something is messed up with the environment when building like this.

It all builds fine in a Yakkety and Xenial PPA (https://code.launchpad.net/~libertine-team/+archive/ubuntu/devel/+packages).

Is it a requirement for this to build correctly in a base pbuilder chroot on one's system?

[Michael Terry (mterry)]

A team bug subscriber to LP bugs. Just go to https://bugs.launchpad.net/ubuntu/+source/libertine and subscribe a team there. We just want to make sure that someone is looking after the package (and we prefer a team vs individual for that, for obvious reasons).

~libertine-team is not terrible. My preference is for one of the teams already on our package subscriber list, so that I don't have to add another one. :)

http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/package-subscribers#L107

But if there isn't another team that would make sense, libertine-team is OK.

---

As for the pbuilder failure, no, it's not a requirement. It's just how I check whether your package is ftbfs. But if it has built recently in a PPA, which uses a slightly different build environment, that's more trustworthy.

Though still, would be nice to fix pbuilder builds. But not a blocker.

[Christopher Townsend (townsend)]

After discussing with Stephen, we feel ~libertine-team is the best team for this as Libertine is used on phone/tablet as well as desktop. We have already subscribed ~libertine-team to all Libertine source package bugs now.

Let me know if there is anything else I need to do to get this in main.

Thanks!

[Adam Conrad (adconrad)]

Promoted to main.

[Steve Langasek (vorlon)]

I am concerned about the use of the libertine-team as the designated subscriber for this because of the granularity of this team; it appears to currently be a reasonably-sized team, but it also seems this is a one-off project team which I could imagine would have its membership reduced later as the project matures and engineering resources are allocated elsewhere.

It's certainly appropriate for the libertine-team to follow the bugs for this project, but with a bug subscriber we also want to be able to answer the question, "organizationally, who is responsible for problems in this package long term if we need to escalate?" For that it is usually better to use a smaller number of teams that have a fairly stable mapping to the Canonical org chart, which I'm not sure is true for this team.

This is an existing problem with many of the client stack packages in main, so I don't consider this a blocker for libertine right now (and it's quite urgent that we get libertine into main to unblock image builds). Will add libertine-team to our list of known teams for now, but I think we want to revisit this later as part of a review of the client stack ownership generally.