Provide pkg-config pc files

[Khaled Hosny]

[Impact]

 * The upstream version of icu we ship, has pkg-config files in the upstream tarball, but they are not installed into any of the binary packages.

 * If software correctly relies on this upstream icu version, it's not unreasonable to depend on pkg-config files being present. Apart from that they aren't here.

 * While everything in the archive builds, new software build in a jhbuild doesn't. Jhbuild is used to build large scale upstream projects and many developers choose to run last stable release & do their development there. Hence it should be supported.

[Test Case]

$ pkg-config --list-all | grep icu-
icu-i18n icu-i18n - International Components for Unicode: Internationalization library
icu-uc icu-uc - International Components for Unicode: Common and Data libraries
icu-io icu-io - International Components for Unicode: Stream and I/O Library
icu-le icu-le - International Components for Unicode: Layout library
icu-lx icu-lx - International Components for Unicode: Paragraph Layout library

* Above command should succeed with output shown.
* Other tests are compiling & linking icu-* using pkg-config as for example done by harfbuzz

[Regression Potential]

* If some piece of software in quantal used auto-detection of icu-* based on pkg-config files, it means in quantal-release & quantal-security it will continue to build without linking icu; but in an SRU it will pick up linking against icu. In practice, we need check that libicu-dev rdepends do not do so. That would be sufficient, because all our builds are done in minimal / clean chroots.

[Steven R. Loomis (srl-icu-project)]

Supporting these will allow users to ignore the bad old "icu-config" method. Strongly support this.

Note that redhat had briefly synthesized "icu.pc" but this is not correct, there are multiple icu-*.pc files for various subcomponents.

[Launchpad Janitor (janitor)]

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

[Thomas Bechtold (toabctl)]

Because of the missing .pc files it's impossible to build gnome-control-center within jhbuild

[Dimitri John Ledkov (xnox)]

We have lived without this for over 3 years now, see http://bugs.icu-project.org/trac/ticket/6981 filed in 2009.

As for gnome-control-center, itt looks like it builds fine in Ubuntu:
https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu16

Can you please list packages in the archive try to use the not yet existing in the archive icu-*.pc files?

[Thomas Bechtold (toabctl)]

I tried to build gnome-control-center 3.6 from upstream git with jhbuild. I think that's something important because Ubuntu uses the GNOME stack so Ubuntu users should be able to improve the software.

The argument that we lived without the .pc files for 3 years is a bit weird - we also lived without unity for many years but it's here (and it's cool).

And the bug http://bugs.icu-project.org/trac/ticket/6981 is already solved and the .pc files are generated. We just have to install the files.

So what's the reason to not include the files?

[Dimitri John Ledkov (xnox)]

Grep in gnome-control-center source package in ubuntu and the git repository reveal no direct icu usage. Are you sure it's not some other component? Also jhbuild sets trivially allow one building all reverse-depends include core components and patching stuff if needed.

The risk is high here.

We are late in the cycle and will not have time to fix issues from another full-archive rebuild.
icu is a core component, if for example some software detects icu-*.pc files and prefers those above icu-config and there is a bug in icu-*.pc usage.... then an SRU or security update might simply not build. That would be really bad. The risk is too high here.

Did you rebuild all reverse dependencies all the way up? or did a static analysis on those?

[Colin Watson (cjwatson)]

Not committing to this for 12.10 at this point. (It seems like a more reasonable proposition for 13.04.)

[Dominik Röttsches (drott)]

I'd need this to be able to compile recent versions of Harfbuzz-ng who look for icu pc files.

[Thomas Bechtold (toabctl)]

This patch is a debdiff to solve the problem.

[Dimitri John Ledkov (xnox)]

The debdiff attached did not have correct maintainer set.
Next time, please run `update-maintainer` after bumping the changelog.

Also that means the source package failed to build on my, ubuntu, machine.
I did full test build in sbuild and confirmed that the pc files are present, but did not check their correctness.

Please test compile against them, when they become available. If possible, please add autopkgtest that does "build, link, run" test against function call provided by icu API / those pc files.

[Launchpad Janitor (janitor)]

This bug was fixed in the package icu - 4.8.1.1-9ubuntu1

---------------
icu (4.8.1.1-9ubuntu1) raring; urgency=low

  * debian/libicu-dev.install: Install .pc files (LP: #1037588).
 -- Thomas Bechtold <email address hidden> Tue, 13 Nov 2012 12:16:57 +0100

[Sebastian Geiger (lanoxx)]

Please also commit this fix to 12.10. These package config files are required for some software to compile (such as gnome, anjuta, gtk+).

[Dimitri John Ledkov (xnox)]

@ Lanoxx: quantal archive has built gnome, anjuta & gtk+ without these .pc files.

Can you please actually give an example of what does not build? Also see my previous comment #8 requestion evidence of things failing to build from source.

[Sebastian Geiger (lanoxx)]

Hi Dmitrijs,

here is the output of jhbuild:

lanoxx@earth ~/Documents/Code/jh-gnome-checkout $jhbuild build anjuta
Required packages:
  System installed packages which are too old:
    (none)
  No matching system package installed:
    wireless-tools (required=25)
    libicu (icu-i18n.pc, required=4)
jhbuild build: Required system dependencies not installed. Install using the command 'jhbuild sysdeps --install' or to ignore system dependencies use command-line option --nodeps

----------------------------------------------------------------------------

lanoxx@earth ~/Documents/Code/jh-gnome-checkout $jhbuild sysdeps anjuta --install
[...]
Required packages:
  System installed packages which are too old:
    (none)
  No matching system package installed:
    libicu (icu-i18n.pc, required=4)
    wireless-tools (required=25)
Optional packages: (JHBuild will build the missing packages)
  System installed packages which are too old:
    WebKit (webkitgtk-3.0.pc, required=1.10.2, installed=1.10.0)
    js185 (mozjs185.pc, required=1.0.0)
  No matching system package installed:
I: Installing dependencies on system: libicu wireless-tools
I: Using apt-file to search for providers; this may be slow. Please wait.
I: No native package found for libicu (/icu-i18n.pc)
I: No native package found for wireless-tools (/usr/include/wireless.h)
I: Nothing to install

This is the output of jhbuild, I would be happy if you could tell me how to build anjuta without these packages.

[Dimitri John Ledkov (xnox)]

Please use, icu jhbuild module. If not available, ask gnome to provide icu jhbuild module. Install raring icu into jhbuild chroot.

You are compiling source code from upstream GNOME, which does add dependencies higher & quicker than stable releases of linux distributions. Note that from above icu is not your only problem, webkit & mozjs are also too old.

For support in compiling GNOME git master => seek help from GNOME upstream.

[Allison Karlitskaya (desrt)]

Rebuilding the quantal package with the patch in this bug fixes the problem. I appreciate the reasons for not uploading this as an SRU but I think the least we can do is to offer a quantal package in the desktop-team PPA.

Meanwhile, upstream jhbuild tries very hard not to introduce depdencies that would prevent it from building in stable releases of Ubuntu (being one of its primary target platforms). For example, our version of libicu is totally fine (except for this bug) and the webkit and js185 dependencies you mention are listed in the "Optional" section above (and indeed, jhbuild is happy to build those....)

[Sebastian Geiger (lanoxx)]

[RANT ON]
The main reason I want to compile stuff is because I want to help Ubuntu and upstream Gnome to write patches and fix bugs. But I really have better things to do than wasting my time with these kinds of errors. It seems to be simply not possible to JUST get the code for an application, and then engage in a happy cycle of hack, build and debug. Instead one has to learn a million of different tools, become an expert with jhbuild, automake, packaging and dependency management and other little tools. And additionally the process fails way too ofter because of missing stuff, incompatible versions or because of stupid bugs like this one. Most of the time hours are lost already way be fore I can touch a single line of code.

I really don't understand why this process cant be a little simpler or at least quality control a bit better to avoid putting these unnecessary stones at peoples feet. Doesn't Ubuntu want to attract new developers?
[RANT OFF]

[Jeremy Bícha (jbicha)]

Lanoxx, we have now added the patched icu to the Ubuntu Desktop PPA. It's currently the only package there for Quantal so it should be a fairly safe PPA to add.

https://launchpad.net/~ubuntu-desktop/+archive/ppa/

Our sincere apologies for the inconvenience. It looks like there is uncertainty whether this qualifies for our regular SRU procedures but this at least is the quickest solution.

[Sebastian Geiger (lanoxx)]

Jeremy, thank you very much. I will try to install it and report back if I am able to build the software afterwards.

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".