Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Gianfranco Costamagna]

control: close -1
Hello Tomasz

On Fri, 5 Nov 2021 23:19:30 +0100 Tomasz Wolak  wrote:
> Hello Gianfranco,
> 
> On 10/27/21 10:13 AM, Gianfranco Costamagna wrote:
> > Hello Tomasz
> > 
> > On Wed, 20 Oct 2021 19:58:47 +0200 Tomasz Wolak  
> > wrote:
> >> [...]
> >> I have tried to build the source package 0.7.0
> >> (https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian
> >> (bullseye), but unfortunately building the package fails with:
> >>
> > 
> > https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental
> > 
> > 0.7.0+dfsg-5 should be buildable correctly, the package was broken due to 
> > missing
> > symbols
> > 
> > please give it another shot if possible :)
> > 
> > Gianfranco
> > 
> > 
> 
> Yes, the version 0.7.0+dfsg-5 builds on Bullseye and both pkg-config and 
> CMake's find_package() return "" (an empty string) as include directory 
> for yaml-cpp. The library's header files are under system's generic 
> /usr/include ( /usr/include/yaml-cpp/ in this case) - so it seems 
> correct to me as it is fine for compilation (as long as source files are 
> using the relative path ).
> 
> I was a bit confused though, as the software that I was building 
> (RStudio, www.rstudio.com, the latest released version 
> rstudio-2021.09.0-351) was still failing - because its CMake script 
> checks if the include directory (provided in YAML_CPP_INCLUDE_DIR) 
> exists... This seems to me a bad practice considering the above (no 
> additional include paths may be needed for correct compilation).
> However, this varies also between different libraries - for some, the 
> tools returns an absolute path to their subdirectory, eg. for uuid, 
> pkg-config returns -I/usr/include/uuid; for SDL2 both pkg-config and 
> CMake points to /usr/include/SDL2 etc.). In such case, RStudio 
> developers' approach would be correct...
> 
> Is there a (at least recommended) standard for this or each library goes 
> its own way? (I suppose Debian does not enforce this, just follows the 
> original).
> 
> Anyway - 0.7.0 seems OK. (backported to Bullseye will fix the problem 
> with CMake).

I think this depends on single libraries, this is something probably for 
yaml-cpp upstream developers
(I think it depends on the "real clash use case scenario"


If you look at the header file names, you can find e.g.
/usr/include/yaml-cpp/anchor.h
/usr/include/yaml-cpp/binary.h
/usr/include/yaml-cpp/contrib/anchordict.h
/usr/include/yaml-cpp/contrib/graphbuilder.h
/usr/include/yaml-cpp/depthguard.h
/usr/include/yaml-cpp/dll.h
/usr/include/yaml-cpp/emitfromevents.h
/usr/include/yaml-cpp/emitter.h
/usr/include/yaml-cpp/emitterdef.h
/usr/include/yaml-cpp/emittermanip.h
/usr/include/yaml-cpp/emitterstyle.h
/usr/include/yaml-cpp/eventhandler.h
/usr/include/yaml-cpp/exceptions.h
/usr/include/yaml-cpp/mark.h
/usr/include/yaml-cpp/node/convert.h
/usr/include/yaml-cpp/node/detail/bool_type.h
/usr/include/yaml-cpp/node/detail/impl.h
/usr/include/yaml-cpp/node/detail/iterator.h
/usr/include/yaml-cpp/node/detail/iterator_fwd.h
/usr/include/yaml-cpp/node/detail/memory.h
/usr/include/yaml-cpp/node/detail/node.h
/usr/include/yaml-cpp/node/detail/node_data.h
/usr/include/yaml-cpp/node/detail/node_iterator.h
/usr/include/yaml-cpp/node/detail/node_ref.h
/usr/include/yaml-cpp/node/emit.h
/usr/include/yaml-cpp/node/impl.h
/usr/include/yaml-cpp/node/iterator.h
/usr/include/yaml-cpp/node/node.h
/usr/include/yaml-cpp/node/parse.h
/usr/include/yaml-cpp/node/ptr.h
/usr/include/yaml-cpp/node/type.h
/usr/include/yaml-cpp/noncopyable.h
/usr/include/yaml-cpp/null.h
/usr/include/yaml-cpp/ostream_wrapper.h
/usr/include/yaml-cpp/parser.h
/usr/include/yaml-cpp/stlemitter.h
/usr/include/yaml-cpp/traits.h
/usr/include/yaml-cpp/yaml.h


Including  or  without yaml-cpp prepending might lead to broken 
builds, and incorrect behaviour.
Usually the header names should be not so generic, but this seems not to be 
yaml-cpp case.

So, for me,  is *really* the best choice

E.g. this is what we have in Debian
libyaml-cpp-dev: /usr/include/yaml-cpp/yaml.h
libyaml-dev: /usr/include/yaml.h

(same for other headers here!)

So, for me prepending yaml-cpp is the "golden solution".

I'm closing this one, I presume the transition will start soon in sid

Gianfranco

> 
> Thank you.
> 
> Tomasz
> 
> 

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Tomasz Wolak]

Hello Gianfranco,

On 10/27/21 10:13 AM, Gianfranco Costamagna wrote:

Hello Tomasz

On Wed, 20 Oct 2021 19:58:47 +0200 Tomasz Wolak  wrote:

[...]
I have tried to build the source package 0.7.0
(https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian
(bullseye), but unfortunately building the package fails with:



https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental

0.7.0+dfsg-5 should be buildable correctly, the package was broken due to 
missing
symbols

please give it another shot if possible :)

Gianfranco




Yes, the version 0.7.0+dfsg-5 builds on Bullseye and both pkg-config and 
CMake's find_package() return "" (an empty string) as include directory 
for yaml-cpp. The library's header files are under system's generic 
/usr/include ( /usr/include/yaml-cpp/ in this case) - so it seems 
correct to me as it is fine for compilation (as long as source files are 
using the relative path ).


I was a bit confused though, as the software that I was building 
(RStudio, www.rstudio.com, the latest released version 
rstudio-2021.09.0-351) was still failing - because its CMake script 
checks if the include directory (provided in YAML_CPP_INCLUDE_DIR) 
exists... This seems to me a bad practice considering the above (no 
additional include paths may be needed for correct compilation).
However, this varies also between different libraries - for some, the 
tools returns an absolute path to their subdirectory, eg. for uuid, 
pkg-config returns -I/usr/include/uuid; for SDL2 both pkg-config and 
CMake points to /usr/include/SDL2 etc.). In such case, RStudio 
developers' approach would be correct...


Is there a (at least recommended) standard for this or each library goes 
its own way? (I suppose Debian does not enforce this, just follows the 
original).


Anyway - 0.7.0 seems OK. (backported to Bullseye will fix the problem 
with CMake).


Thank you.

Tomasz

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Gianfranco Costamagna]

Hello Tomasz

On Wed, 20 Oct 2021 19:58:47 +0200 Tomasz Wolak  wrote:
> Hi Gianfranco,
> 
> Thanks for having a look at the issue.
> 
> On Thu, 14 Oct 2021 19:17:53 +0200 Gianfranco Costamagna 
>  wrote:
>  > Hello Tomasz
>  > […]
>  > can you please check if 0.7.0 in debian/experimental fixes this issue?
>  > The cmake scripts have been reworked, and I can't see anymore the 
> variable not correctly evaluated.
>  >
>  > In case please let me know if the bug is fixed
>  >
>  > thanks
>  >
>  > Gianfranco
>  >
> 
> I have tried to build the source package 0.7.0 
> (https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian 
> (bullseye), but unfortunately building the package fails with:
> 

https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental

0.7.0+dfsg-5 should be buildable correctly, the package was broken due to 
missing
symbols

please give it another shot if possible :)

Gianfranco


> 
> nm --dynamic --defined-only build-shared/libyaml-cpp.so | awk '$2 ~ /W/ 
> { print " " $3 "@Base 0.7.0" } ' > debian/weak-symbols
> dh_makeshlibs -VNone
> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
> see diff output below
> dpkg-gensymbols: error: some symbols or patterns disappeared in the 
> symbols file: see diff output below
> dpkg-gensymbols: warning: debian/libyaml-cpp0.7/DEBIAN/symbols doesn't 
> match completely debian/libyaml-cpp0.7.symbols
> [...]
> dh_makeshlibs: error: failing due to earlier errors
> make[1]: *** [debian/rules:62: override_dh_makeshlibs] Error 25
> make[1]: Leaving directory '/home/debian/tmp/yaml-cpp-0.7.0+dfsg'
> make: *** [debian/rules:71: binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess 
> returned exit status 2
> debuild: fatal error at line 1182:
> dpkg-buildpackage -us -uc -ui -i -b failed
> 
> 
> It passes compilation and tests but fails on the
> "Install the project..." part.
> 
> In consequence, I cannot see what would be in the built package to be 
> sure, but the configuration files for cmake seem to be generated. The 
> contents of the generated file 
> yaml-cpp-0.7.0+dfsg/build-shared/yaml-cpp-config.cmake
> is as follows:
> 
> 
> # - Config file for the yaml-cpp package
> # It defines the following variables
> #  YAML_CPP_INCLUDE_DIR - include directory
> #  YAML_CPP_LIBRARIES- libraries to link against
> 
> # Compute paths

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Tomasz Wolak]

Hi Gianfranco,

Thanks for having a look at the issue.

On Thu, 14 Oct 2021 19:17:53 +0200 Gianfranco Costamagna 
 wrote:

> Hello Tomasz
> […]
> can you please check if 0.7.0 in debian/experimental fixes this issue?
> The cmake scripts have been reworked, and I can't see anymore the 
variable not correctly evaluated.

>
> In case please let me know if the bug is fixed
>
> thanks
>
> Gianfranco
>

I have tried to build the source package 0.7.0 
(https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian 
(bullseye), but unfortunately building the package fails with:



nm --dynamic --defined-only build-shared/libyaml-cpp.so | awk '$2 ~ /W/ 
{ print " " $3 "@Base 0.7.0" } ' > debian/weak-symbols

dh_makeshlibs -VNone
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the 
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libyaml-cpp0.7/DEBIAN/symbols doesn't 
match completely debian/libyaml-cpp0.7.symbols

[...]
dh_makeshlibs: error: failing due to earlier errors
make[1]: *** [debian/rules:62: override_dh_makeshlibs] Error 25
make[1]: Leaving directory '/home/debian/tmp/yaml-cpp-0.7.0+dfsg'
make: *** [debian/rules:71: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess 
returned exit status 2

debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed


It passes compilation and tests but fails on the
"Install the project..." part.

In consequence, I cannot see what would be in the built package to be 
sure, but the configuration files for cmake seem to be generated. The 
contents of the generated file 
yaml-cpp-0.7.0+dfsg/build-shared/yaml-cpp-config.cmake

is as follows:


# - Config file for the yaml-cpp package
# It defines the following variables
#  YAML_CPP_INCLUDE_DIR - include directory
#  YAML_CPP_LIBRARIES- libraries to link against

# Compute paths
get_filename_component(YAML_CPP_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
set(YAML_CPP_INCLUDE_DIR "")

# Our library dependencies (contains definitions for IMPORTED targets)
include("${YAML_CPP_CMAKE_DIR}/yaml-cpp-targets.cmake")

# These are IMPORTED targets created by yaml-cpp-targets.cmake
set(YAML_CPP_LIBRARIES "")


so it does not seem correct (both include and libs settings are empty...).

I do not know the process of fixing bugs in Debian (ie. whether you 
rather backport a newer version from testing/unstable or fix current 
version), but at the moment it seems to me that it would be easier to 
fix the current package (0.6.3) and just make it usable with cmake than 
backporting 0.7.0 (which seems to have more complex issues when building 
on bullseye).


Cheers,
Tomasz

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Gianfranco Costamagna]

Hello Tomasz

On Fri, 01 Oct 2021 00:04:51 +0200 Tomasz Wolak  wrote:
> Package: libyaml-cpp-dev
> Version: 0.6.3-9
> Severity: normal
> X-Debbugs-Cc: tomas.wo...@gmail.com
> 
> One of the package config files for CMake:
> 
> /usr/lib/x86_64-linux-gnu/cmake/yaml-cpp/yaml-cpp-config.cmake
> 
> contains an incorrect path to the library's header files:
> 'include' instead of '/usr/include/yaml-cpp'.
> 
> I have managed to hot-fix this by correcting debian patches:
> 
> 1. install-cmake-dev-files.patch - the line (for CMakeLists.txt):
>  set(INCLUDE_INSTALL_ROOT_DIR include)
> was changed to:
> -set(INCLUDE_INSTALL_ROOT_DIR include)
> +set(INCLUDE_INSTALL_ROOT_DIR /usr/include)
> 
> 2. fix-pkg-config.patch, where I changed the line:
> +set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_ROOT_DIR@")
> to the following:
> +set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_DIR@")
> 
> After changing this, the rebuilt package contains the correct
> path to the header files (/usr/include/yaml-cpp) in its cmake
> configuration.
> 
> (I am not sure if this is the best way for fixing this but it seems
> reasonable. It should be reviewed and tested, of course.
> I am not sure how to provide you a patch to a Debian patch...
> that's why such descriptive form).
> 
> (Btw. version 0.6.3-10 seems to have the same problem).
> 
> 


can you please check if 0.7.0 in debian/experimental fixes this issue?
The cmake scripts have been reworked, and I can't see anymore the variable not 
correctly evaluated.

In case please let me know if the bug is fixed

thanks

Gianfranco

> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libyaml-cpp-dev depends on:
> ii  libyaml-cpp0.6  0.6.3-9
> 
> libyaml-cpp-dev recommends no packages.
> 
> libyaml-cpp-dev suggests no packages.
> 
> -- no debconf information
> 

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Tomasz Wolak]

Package: libyaml-cpp-dev
Version: 0.6.3-9
Severity: normal
X-Debbugs-Cc: tomas.wo...@gmail.com

One of the package config files for CMake:

/usr/lib/x86_64-linux-gnu/cmake/yaml-cpp/yaml-cpp-config.cmake

contains an incorrect path to the library's header files:
'include' instead of '/usr/include/yaml-cpp'.

I have managed to hot-fix this by correcting debian patches:

1. install-cmake-dev-files.patch - the line (for CMakeLists.txt):
 set(INCLUDE_INSTALL_ROOT_DIR include)
was changed to:
-set(INCLUDE_INSTALL_ROOT_DIR include)
+set(INCLUDE_INSTALL_ROOT_DIR /usr/include)

2. fix-pkg-config.patch, where I changed the line:
+set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_ROOT_DIR@")
to the following:
+set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_DIR@")

After changing this, the rebuilt package contains the correct
path to the header files (/usr/include/yaml-cpp) in its cmake
configuration.

(I am not sure if this is the best way for fixing this but it seems
reasonable. It should be reviewed and tested, of course.
I am not sure how to provide you a patch to a Debian patch...
that's why such descriptive form).

(Btw. version 0.6.3-10 seems to have the same problem).


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libyaml-cpp-dev depends on:
ii  libyaml-cpp0.6  0.6.3-9

libyaml-cpp-dev recommends no packages.

libyaml-cpp-dev suggests no packages.

-- no debconf information