Created attachment 2053 [details]
temporary patch for testing

Tim, Slavek, this is a strange bug. Please read through, since I need your collaboration to test/fix on Ubuntu.

1) PROBLEM AND FIX
The reason for the FTBFS is that libgadu is not detected by cmake in a clean build environment. cmake executes the command "/usr/bin/pkg-config --exists libgadu": this fails because pkg-config can not find the package "gnutls", as shown by:
--------------
#> if `/usr/bin/pkg-config --exists libgadu`; then echo 1; else echo 0; fi
0

#> /usr/bin/pkg-config --exists libgadu --print-errors
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gnutls', required by 'libgadu', not found
--------------

Installing the package "libgnutls-dev" is sufficient to fix the problem (and that is the reason why on my local machine the build was successful):
--------------
#> if `/usr/bin/pkg-config --exists libgadu`; then echo 1; else echo 0; fi
1

#> /usr/bin/pkg-config --exists libgadu --print-errors
<No output>
--------------

I verified that after adding "libgnutls-dev" to the control file (see patch), tdenetwork builds properly in Jessie.


2) REASON OF PROBLEM
I have not (yet) been able to find what triggered the problem. I last successfully built tdenetwork on Apr. 26 and I discovered a FTBFS on May 4/5.
The last change to cmake and cmake-data package is dated Mar.30, the last change to pkg-congif is dated Apr.23.
Even more strange, checking the log file of the nightly build website (dated Apr. 29) I can see that the libgnutls-dev package was not installed and the following message appears:
---------------------
-- checking for one of the modules 'libgadu'
Package gnutls was not found in the pkg-config search path.
Perhaps you should add the directory containing `gnutls.pc'
to the PKG_CONFIG_PATH environment variable
[repeated several times]
---------------------
But the build process continued correctly until the end.

Adding the "libgnutls-dev" to the control file would also fix those messages, but yet I am wondering what has changed.


3) UBUNTU PROBLEM (?)
Checking the availability of "libgnutls-dev" for Ubuntu, is looks like some releases do not have such package, specifically maverick, natty, oneiric, quantal.
http://packages.ubuntu.com/search?keywords=libgnutls-dev
So the same solution can no be applied, provided the same problem arise.

How do you think we should move forward?

(In reply to Michele Calgaro from comment #1)
> Created attachment 2053 [details]
> temporary patch for testing
> 
> Tim, Slavek, this is a strange bug. Please read through, since I need your
> collaboration to test/fix on Ubuntu.
> 
> 1) PROBLEM AND FIX
> The reason for the FTBFS is that libgadu is not detected by cmake in a clean
> build environment. cmake executes the command "/usr/bin/pkg-config --exists
> libgadu": this fails because pkg-config can not find the package "gnutls",
> as shown by:
> --------------
> #> if `/usr/bin/pkg-config --exists libgadu`; then echo 1; else echo 0; fi
> 0
> 
> #> /usr/bin/pkg-config --exists libgadu --print-errors
> Package gnutls was not found in the pkg-config search path.
> Perhaps you should add the directory containing `gnutls.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'gnutls', required by 'libgadu', not found
> --------------
> 
> Installing the package "libgnutls-dev" is sufficient to fix the problem (and
> that is the reason why on my local machine the build was successful):
> --------------
> #> if `/usr/bin/pkg-config --exists libgadu`; then echo 1; else echo 0; fi
> 1
> 
> #> /usr/bin/pkg-config --exists libgadu --print-errors
> <No output>
> --------------
> 
> I verified that after adding "libgnutls-dev" to the control file (see
> patch), tdenetwork builds properly in Jessie.
> 
> 
> 2) REASON OF PROBLEM
> I have not (yet) been able to find what triggered the problem. I last
> successfully built tdenetwork on Apr. 26 and I discovered a FTBFS on May 4/5.
> The last change to cmake and cmake-data package is dated Mar.30, the last
> change to pkg-congif is dated Apr.23.
> Even more strange, checking the log file of the nightly build website (dated
> Apr. 29) I can see that the libgnutls-dev package was not installed and the
> following message appears:
> ---------------------
> -- checking for one of the modules 'libgadu'
> Package gnutls was not found in the pkg-config search path.
> Perhaps you should add the directory containing `gnutls.pc'
> to the PKG_CONFIG_PATH environment variable
> [repeated several times]
> ---------------------
> But the build process continued correctly until the end.
> 
> Adding the "libgnutls-dev" to the control file would also fix those
> messages, but yet I am wondering what has changed.
> 
> 
> 3) UBUNTU PROBLEM (?)
> Checking the availability of "libgnutls-dev" for Ubuntu, is looks like some
> releases do not have such package, specifically maverick, natty, oneiric,
> quantal.
> http://packages.ubuntu.com/search?keywords=libgnutls-dev
> So the same solution can no be applied, provided the same problem arise.
> 
> How do you think we should move forward?

Ubuntu has a habit of splitting monolithic packages into many smaller packages somewhat at random.  My best guess as to what happened (without diving into the Ubuntu changelogs) would be that one or more packages happened to build-dep on libgnutls-dev, and that this was fixed/changed upstream rather recently, thus exposing our failure to properly build-dep on libgnutls-dev where needed.

FYI, maverick, natty, oneiric, and quantal are no longer searchable on packages.ubuntu.com due to deprecation and removal.  libgnutls-dev exists on those platforms, so don't worry about it.

Tim

Interesting. Previously, libgnutls-dev installed because of dependencies for tdelibs14-trinity-dev. On Jessie not.

As Tim said, on all currently supported Ubuntu package libgnutls-dev exists, you can safely add a dependency. So, go ahead and push the patch.

Tim, Slavek, thanks for your feedback.
Fixed in commit ab15c5b.

Unfortunately I have to reopen this, and unfortunately it's currently blocking R14 RC1.  The changes to the tdenetwork packaging have made it unbuildable on Ubuntu Precise through Trusty; an example of the build failure is shown in this log: 

https://librarian.quickbuild.pearsoncomputing.net/6539934/buildlog_ubuntu-precise-amd64.tdenetwork-trinity_4%3A14.0.0-r363-0ubuntu12.04.0%2Bpr53_MANUALDEPWAIT.txt.gz

What it boils down to is the new or select is preferentially choosing libgnutls28-dev over libgnutls-dev when looking for gnutls-dev.  While this may seem innocuous the core TDE development packages depend on libcups2-dev, which in turn depends on libgnutls-dev.  Due to this conflict apt is unable to fulfill all build dependencies as shown above and the builds fail.

Do we need the dependency on gnutls-dev or can we hard depend on libgnutls-dev?

Thanks!

> What it boils down to is the new or select is preferentially choosing 
> libgnutls28-dev over libgnutls-dev when looking for gnutls-dev
Tim, when did the problem start happening? I do not build for Ubuntu, but the fix for this bug went in about 6 months ago, so I find quite strange that we didn't spot it before.

(In reply to Michele Calgaro from comment #6)
> > What it boils down to is the new or select is preferentially choosing 
> > libgnutls28-dev over libgnutls-dev when looking for gnutls-dev
> Tim, when did the problem start happening? I do not build for Ubuntu, but
> the fix for this bug went in about 6 months ago, so I find quite strange
> that we didn't spot it before.

This relates to commit 2fc1e7d9 (relates to libgadu update on Jessie).

Here again showed difference in processing dependencies between build-farm and pbuilder. For me, everything builds perfectly fine with pbuilder.

I'll take care of it.

(In reply to Slávek Banko from comment #7)
> (In reply to Michele Calgaro from comment #6)
> > > What it boils down to is the new or select is preferentially choosing 
> > > libgnutls28-dev over libgnutls-dev when looking for gnutls-dev
> > Tim, when did the problem start happening? I do not build for Ubuntu, but
> > the fix for this bug went in about 6 months ago, so I find quite strange
> > that we didn't spot it before.
> 
> This relates to commit 2fc1e7d9 (relates to libgadu update on Jessie).
> 
> Here again showed difference in processing dependencies between build-farm
> and pbuilder. For me, everything builds perfectly fine with pbuilder.
> 
> I'll take care of it.

Sounds good.  One of the reasons for using QuickBuild (a rebranded Launchpad instance) vs. a custom setup is that the former is both ubiquitous (every Ubuntu user knows about PPAs!) and very strict.  Ubuntu rebuilds their entire base archives on their Launchpad system, so I am fairly confident in saying pbuilder is doing something wrong here.

(In reply to Timothy Pearson from comment #8)
> (In reply to Slávek Banko from comment #7)
> > (In reply to Michele Calgaro from comment #6)
> > > > What it boils down to is the new or select is preferentially choosing 
> > > > libgnutls28-dev over libgnutls-dev when looking for gnutls-dev
> > > Tim, when did the problem start happening? I do not build for Ubuntu, but
> > > the fix for this bug went in about 6 months ago, so I find quite strange
> > > that we didn't spot it before.
> > 
> > This relates to commit 2fc1e7d9 (relates to libgadu update on Jessie).
> > 
> > Here again showed difference in processing dependencies between build-farm
> > and pbuilder. For me, everything builds perfectly fine with pbuilder.
> > 
> > I'll take care of it.
> 
> Sounds good.  One of the reasons for using QuickBuild (a rebranded Launchpad
> instance) vs. a custom setup is that the former is both ubiquitous (every
> Ubuntu user knows about PPAs!) and very strict.  Ubuntu rebuilds their
> entire base archives on their Launchpad system, so I am fairly confident in
> saying pbuilder is doing something wrong here.

With pbuilder dependencies for package is resolved by creating an empty package (pbuilder-satisfydepends-dummy) with these dependencies, and then uses standard aptitude to install dependencies in a clean chroot. Does not have its own specific magic. I definitely would not say that pbuilder doing something wrong, because the dependencies are installed by a standard aptitude :)

I hope to problem is fixed by commit 0b8b58d1.

Much closer, but Utopic still fails:
https://librarian.quickbuild.pearsoncomputing.net/6546984/buildlog_ubuntu-utopic-amd64.tdenetwork-trinity_4%3A14.0.0-r363-0ubuntu14.10.0%2Bpr54_MANUALDEPWAIT.txt.gz

Checking correctness of source dependencies...
After installing, the following source dependencies are still unsatisfied:
libgadu-dev(inst 1:1.12.0-3 ! >> wanted 1:1.12.0-3)|libgnutls-dev(missing)

My first instict is to change that >> to >= ; is there any reason why this should not be done?

Regarding pbuilder vs. launchpad, almost every Ubuntu package (official or custom) goes through a Launchpad-based build process.  A very few custom packages (such as the ones you are building) go through a pbuilder-based build process.  As a result, even if pbuilder is more correct (which I still doubt) market share alone dictates that we get these packages to build properly on Launchpad.

Thanks!

Tim

The point is that 'libgadu-dev' needs gnutls devel package, but only starting with version 1:1.12.0-4 has it as a dependency. Therefore, the condition to version >> 1.1.12.0-3 is correct.

I have good news! Pbuilder has a choice of dependency solver - namely classic, aptitude, gdebi and experimental. As I tested, the first three will solve the dependency correctly, only experimental behaves the same as the build-farm. It therefore seems a good way to test locally on pbuilder before commit!

Anyway, from what I can see, so solver 'experimental' ignores version condition (ie >>1:1.12.0-3) at the time of selection from variable dependencies, and this condition is checked when it is too late => causes FTBFS. This really is not the correct behavior.

Since the conflict libgnutls-dev x libgnutls28-dev, which previously appeared in debian testing, has been resolved by removing libgnutls-dev, it was possible to modify the condition so that on the build-farm should work correctly.

Should be resolved in commit e9a77f2a.

With the exception of a failure on Utopic amd64 (which looks like an Ubuntu-specific transient bug) tdenetwork now builds properly.

Thanks for the fix, and the information about pbuilder!