Re: Build-Depends :native

[Sven Joachim]

On 2019-06-22 12:20 +0200, Jörg Frings-Fürst wrote:

> Hello,
>
> can someone please tell me a source about the meaning of :native in the
> Build-Depends?

The architecture you are building on, see deb-src-control(5):

,
| An architecture qualifier name can be a real Debian architecture name
| (since dpkg 1.16.5), any (since dpkg 1.16.2) or native (since dpkg
| 1.16.5).  If omitted, the default for Build-Depends fields is the
| current host architecture, the default for Build-Conflicts fields is
| any.  A real Debian architecture name will match exactly that
| architecture for that package name, any will match any architecture for
| that package name if the package is marked with Multi-Arch: allowed, and
| native will match the current build architecture if the package is not
| marked with Multi-Arch: foreign.
`

E.g. if your current architecture is amd64, and you are building for
armhf, "Build-Depends: python3:native" means you have to install
python3:amd64 and not python3:armhf.

Cheers,
   Sven

Build-Depends :native

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

can someone please tell me a source about the meaning of :native in the
Build-Depends?

Thanks

CU
Jörg
- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl0OAOsACgkQCfifPIyh
0l2+QA//YB8eWepanSGsArAoiLOmQV7R1uyULiP1OHUN5la7p5eWnw+nW7ej2Gt9
EHtccJhSq/bxiabTwuUBUMcw0UM20V3Ec9BEU5RlzLe9z9jFOiIfinJRw4Ce0tSQ
dVGj3gzbzThhOG/2r2wb+iM8lGkQVA7egewc/NbH/GzCnJvwjdCrnQFo5e/nsWBt
ritTzXvihkR8PSUe2t1oslqViUov0Z19hCIrjalEBfja0ua2gLjq0CQdbxYnZ5xj
IK+xMpHwvpQhS0FC8XywFpY9SP8DhQeC3bCTTLrcZRGrYFQ5NLHpa0HzjZr8HeRP
TODjkpCeAzJyX4Uq01fL/SuuvATBR/PxUkqS5uL0cuG+JXcrXog+LAH5Q6E9MFU4
S7EqAhHGI8sDoli1Ev0HlxWU2fLIBktZeUGN3a5jZLUMbm7BiUlYzgJAJh/y5QVn
+XUlvNkW22PBVAepoCwDh0bEQRyerkGxIXGGmLpXuR8U8lQKhmEtzJvpFCcFmQHp
CzYcsalBJOgBCBu/wrrHxH/E2h/tN8CYK8dDMVv2GLoNeQHtambMMO714zy3Y7VY
W//duHm8061g5ehk9fJId3lwL9EN2byMgVOIlB8NuBTBonYpOW34le6jFbFQYWSk
1vTo3D3OT5QQf/Fsw1JLiJwXyemTvtLJ8oOb70VC+p6oPDsVEXQ=
=ZmA9
-END PGP SIGNATURE-

Re: Build-Depends for a Python wrapper

[Matthew Fernandez]

> On Dec 25, 2018, at 02:41, Geert Stappers  wrote:
> 
> On Mon, Dec 24, 2018 at 06:09:04PM -0800, Matthew Fernandez wrote:
>> Hello Debian Mentors,
>> 
>> I???m preparing to request a piece of software I maintain be made
>> available on Debian and have been doing my homework trying to package
>> it correctly.
>> 
>> It???s a C++ binary, but comes with a Python wrapper for invoking it
>> [0]. This script should run with either Python 2 or Python 3 and
>> requires no non-standard modules, but I???m having trouble getting
>> lintian to approve of it.
>> 
>> In trying to pacify its warnings, I seem to keep causing new
>> ones. The latest is missing-build-dependency-for-dh-addon which seemed
>> straightforward, but I???m having trouble resolving it.
>> 
>> Is it possible I???m just going about this the wrong way? You can see my
>> current fumblings around in the dark for the light switch at [1]. I have
>> not packaged something for Debian before, so apologies if this question
>> is answered elsewhere and my search skills failed me. If you have any
>> time to point me in the right direction, I would be very grateful.
>> 
>> Thanks, Matthew
>> 
>> [0]: 
>> https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
>> [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control
> 
> Multiline Build-Depends
> 
> --- a/debian/control
> +++ b/debian/control
> @@ -2,7 +2,13 @@ Source: rumur
> Section: devel
> Priority: optional
> Maintainer: Matthew Fernandez 
> -Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, 
> flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
> +Build-Depends: debhelper (>= 10)
> +  , bison (>= 3.0)
> +  , cmake (>= 3.1)
> +  , dh-python
> +  , flex (>= 2.5.35)
> +  , libgmp-dev
> +  , python (>= 2.7)
> Standards-Version: 3.9.8
> Homepage: https://github.com/Smattr/rumur
> Vcs-Git: https://github.com/Smattr/rumur.git
> 
> 
> 
> 
> | 
> | $ lintian --info ../rumur_2018.12.20_amd64.changes 
> | E: rumur source: missing-build-dependency-for-dh-addon python3 => 
> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any
> | N: 
> | N:The source package appears to be using a dh addon but doesn't build
> | N:depend on the package that actually provides it. If it uses it, it 
> must
> | N:build depend on it.
> | N:
> | N:Severity: important, Certainty: possible
> | N:
> | N:Check: debhelper, Type: source
> | N: 
> | 
> 
> 
> --- a/debian/control
> +++ b/debian/control
> @@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
>   , flex (>= 2.5.35)
>   , libgmp-dev
>   , python (>= 2.7)
> +  , python3
> Standards-Version: 3.9.8
> Homepage: https://github.com/Smattr/rumur
> Vcs-Git: https://github.com/Smattr/rumur.git
> 
> 
> 
> Find attached two patches that you may apply with `git am  *.patch`
> 
> 
> Groeten
> Geert Stappers

Ah, perfect! It did not occur to me that python and python3 are separate 
packages, and then I misinterpreted lintian’s output. Much appreciated, Geert!

Re: Build-Depends for a Python wrapper

[Geert Stappers]

On Mon, Dec 24, 2018 at 06:09:04PM -0800, Matthew Fernandez wrote:
> Hello Debian Mentors,
>
> I???m preparing to request a piece of software I maintain be made
> available on Debian and have been doing my homework trying to package
> it correctly.
>
> It???s a C++ binary, but comes with a Python wrapper for invoking it
> [0]. This script should run with either Python 2 or Python 3 and
> requires no non-standard modules, but I???m having trouble getting
> lintian to approve of it.
>
> In trying to pacify its warnings, I seem to keep causing new
> ones. The latest is missing-build-dependency-for-dh-addon which seemed
> straightforward, but I???m having trouble resolving it.
>
> Is it possible I???m just going about this the wrong way? You can see my
> current fumblings around in the dark for the light switch at [1]. I have
> not packaged something for Debian before, so apologies if this question
> is answered elsewhere and my search skills failed me. If you have any
> time to point me in the right direction, I would be very grateful.
>
> Thanks, Matthew
>
> [0]: https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
> [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control

Multiline Build-Depends

--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,13 @@ Source: rumur
 Section: devel
 Priority: optional
 Maintainer: Matthew Fernandez 
-Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, 
flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
+Build-Depends: debhelper (>= 10)
+  , bison (>= 3.0)
+  , cmake (>= 3.1)
+  , dh-python
+  , flex (>= 2.5.35)
+  , libgmp-dev
+  , python (>= 2.7)
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git
 



| 
| $ lintian --info ../rumur_2018.12.20_amd64.changes 
| E: rumur source: missing-build-dependency-for-dh-addon python3 => python3:any 
| python3-all:any | python3-dev:any | python3-all-dev:any
| N: 
| N:The source package appears to be using a dh addon but doesn't build
| N:depend on the package that actually provides it. If it uses it, it must
| N:build depend on it.
| N:
| N:Severity: important, Certainty: possible
| N:
| N:    Check: debhelper, Type: source
| N: 
| 


--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
   , flex (>= 2.5.35)
   , libgmp-dev
   , python (>= 2.7)
+  , python3
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git



Find attached two patches that you may apply with `git am  *.patch`


Groeten
Geert Stappers
-- 
Leven en laten leven
From 5e60bee663a51ff6c0a7145ba08855b7c8753c64 Mon Sep 17 00:00:00 2001
From: Geert Stappers 
Date: Tue, 25 Dec 2018 11:15:37 +0100
Subject: [PATCH 1/2] Multilined the Build-Depends

To make further updates on build dependencies more diff friendly.
---
 debian/control | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 550ce5b..d86c6bc 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,13 @@ Source: rumur
 Section: devel
 Priority: optional
 Maintainer: Matthew Fernandez 
-Build-Depends: debhelper (>= 10), bison (>= 3.0), cmake (>= 3.1), dh-python, flex (>= 2.5.35), libgmp-dev, python (>= 2.7)
+Build-Depends: debhelper (>= 10)
+  , bison (>= 3.0)
+  , cmake (>= 3.1)
+  , dh-python
+  , flex (>= 2.5.35)
+  , libgmp-dev
+  , python (>= 2.7)
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git
-- 
2.20.1

From b1b7cb644a625bc20579cf83cb8da7f1a77c173e Mon Sep 17 00:00:00 2001
From: Geert Stappers 
Date: Tue, 25 Dec 2018 11:29:23 +0100
Subject: [PATCH 2/2] Also build depend on python3

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index d86c6bc..815075e 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends: debhelper (>= 10)
   , flex (>= 2.5.35)
   , libgmp-dev
   , python (>= 2.7)
+  , python3
 Standards-Version: 3.9.8
 Homepage: https://github.com/Smattr/rumur
 Vcs-Git: https://github.com/Smattr/rumur.git
-- 
2.20.1



signature.asc
Description: PGP signature

Build-Depends for a Python wrapper

[Matthew Fernandez]

Hello Debian Mentors,

I’m preparing to request a piece of software I maintain be made available on 
Debian and have been doing my homework trying to package it correctly. It’s a 
C++ binary, but comes with a Python wrapper for invoking it [0]. This script 
should run with either Python 2 or Python 3 and requires no non-standard 
modules, but I’m having trouble getting lintian to approve of it. In trying to 
pacify its warnings, I seem to keep causing new ones. The latest is 
missing-build-dependency-for-dh-addon which seemed straightforward, but I’m 
having trouble resolving it. Is it possible I’m just going about this the wrong 
way? You can see my current fumblings around in the dark for the light switch 
at [1]. I have not packaged something for Debian before, so apologies if this 
question is answered elsewhere and my search skills failed me. If you have any 
time to point me in the right direction, I would be very grateful.

Thanks,
Matthew

  [0]: https://github.com/Smattr/rumur/blob/packaging/debian/rumur/src/rumur-run
  [1]: https://github.com/Smattr/rumur/blob/packaging/debian/debian/control

Re: infernal: another autoreconf issue (Was: staden: possibly undefined macro: AC_MSG_ERROR despite pkg-config was added to Build-Depends)

[Yavor Doganov]

Andreas Tille wrote:
> autoheader: warning: missing template: EASEL_COPYRIGHT
> autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])

The problem here is that AC_DEFINE and AC_DEFINE_UNQUOTED are used to
define preprocessor symbols without the third argument which is the
description.  This is fine as long as AC_CONFIG_HEADERS is *not* used.
However, that is not the case -- there are three configuration headers
with separate calls to AC_CONFIG_HEADERS.

The simple, but kinda tiresome solution is to add a third argument to
every AC_DEFINE/AC_DEFINE_UNQUOTED call, like this:

AC_DEFINE_UNQUOTED([EASEL_COPYRIGHT], ["$EASEL_COPYRIGHT"],
   [Easel copyright information.])

Some of the symbols are already documented in the templates provided
by upstream (the .h.in files) but they are invisible to autoheader.

You can also play with AH_TOP/AH_BOTTOM to construct a single
configuration header and put any special things that need to be in the
header templates verbatim, possibly #include'd based on some
conditional.  This is what I'd do if I was upstream, unless the
package really needs separate configuration headers (usually because
some of its components are distributed independently).  I guess this
is exactly what happened -- hhmer and easel were components (external
modules or bundled sources that have their own configure.ac) which
were combined together at some point.

infernal: another autoreconf issue (Was: staden: possibly undefined macro: AC_MSG_ERROR despite pkg-config was added to Build-Depends)

[Andreas Tille]

Hi again,

thanks a lot to Yavor for his patch for staden.  I'd like to come up
with another autoreconf issue which hit me in package infernal[1].
I'm running into

...
   dh_autoreconf
autoheader: warning: missing template: EASEL_COPYRIGHT
autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
autoheader: warning: missing template: EASEL_DATE
autoheader: warning: missing template: EASEL_LICENSE
autoheader: warning: missing template: EASEL_VERSION
autoheader: warning: missing template: HAVE_FLUSH_ZERO_MODE
autoheader: warning: missing template: HAVE_GZIP
autoheader: warning: missing template: HAVE_MPI
autoheader: warning: missing template: HAVE_SSE2
autoheader: warning: missing template: HAVE_SSE2_CAST
autoheader: warning: missing template: HAVE_VMX
autoheader: warning: missing template: HMMER_COPYRIGHT
autoheader: warning: missing template: HMMER_DATE
autoheader: warning: missing template: HMMER_LICENSE
autoheader: warning: missing template: HMMER_THREADS
autoheader: warning: missing template: HMMER_URL
autoheader: warning: missing template: HMMER_VERSION
autoheader: warning: missing template: INFERNAL_COPYRIGHT
autoheader: warning: missing template: INFERNAL_DATE
autoheader: warning: missing template: INFERNAL_LICENSE
autoheader: warning: missing template: INFERNAL_URL
autoheader: warning: missing template: INFERNAL_VERSION
autoheader: warning: missing template: eslDEBUGLEVEL
autoheader: warning: missing template: eslLIBRARY
autoheader: warning: missing template: p7_DEBUGGING
autoheader: warning: missing template: p7_IMPL_SSE
autoheader: warning: missing template: p7_IMPL_VMX
autoreconf: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
...

and I have no idea how to fix this.  Any ideas?

Kind regards

Andreas.

[1] https://salsa.debian.org/med-team/infernal

-- 
http://fam-tille.de

Re: staden: possibly undefined macro: AC_MSG_ERROR despite pkg-config was added to Build-Depends

[Yavor Doganov]

Andreas Tille wrote:
> Since usually the solution is to add pkg-config to Build-Depends
> I tried this but this does not change anything.

I fail to see the reasoning here.

> Any idea how to fix this?

Try the attached patch.  The important fix is adding
AC_CONFIG_MACRO_DIR to configure.in; the changes to
libcurl_check_config.m4 are to silence autoconf warnings.
diff --git a/ac_stubs/libcurl_check_config.m4 b/ac_stubs/libcurl_check_config.m4
index 9b41a73..0c17884 100644
--- a/ac_stubs/libcurl_check_config.m4
+++ b/ac_stubs/libcurl_check_config.m4
@@ -116,7 +116,7 @@ AC_DEFUN([LIBCURL_CHECK_CONFIG],
_libcurl_save_libs=$LIBS
LIBS="$LIBCURL $LIBS"

-   AC_LINK_IFELSE(AC_LANG_PROGRAM([#include ],[
+   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]],[[
 /* Try and use a few common options to force a failure if we are
missing symbols or can't link. */
 int x;
@@ -127,7 +127,7 @@ x=CURLOPT_FILE;
 x=CURLOPT_ERRORBUFFER;
 x=CURLOPT_STDERR;
 x=CURLOPT_VERBOSE;
-]),libcurl_cv_lib_curl_only_needs_minus_l_curl=yes,libcurl_cv_lib_curl_only_needs_minus_l_curl=no)
+]])],libcurl_cv_lib_curl_only_needs_minus_l_curl=yes,libcurl_cv_lib_curl_only_needs_minus_l_curl=no)
 
CPPFLAGS=$_libcurl_save_cppflags
LIBS=$_libcurl_save_libs
@@ -178,7 +178,7 @@ x=CURLOPT_VERBOSE;
_libcurl_save_libs=$LIBS
LIBS="$LIBCURL $LIBS"
 
-   AC_LINK_IFELSE(AC_LANG_PROGRAM([#include ],[
+   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]],[[
 /* Try and use a few common options to force a failure if we are
missing symbols or can't link. */
 int x;
@@ -189,7 +189,7 @@ x=CURLOPT_FILE;
 x=CURLOPT_ERRORBUFFER;
 x=CURLOPT_STDERR;
 x=CURLOPT_VERBOSE;
-]),libcurl_cv_lib_curl_usable=yes,libcurl_cv_lib_curl_usable=no)
+]])],libcurl_cv_lib_curl_usable=yes,libcurl_cv_lib_curl_usable=no)
 
CPPFLAGS=$_libcurl_save_cppflags
LIBS=$_libcurl_save_libs
diff --git a/configure.in b/configure.in
index a3ee01b..ddf3f5e 100644
--- a/configure.in
+++ b/configure.in
@@ -8,6 +8,7 @@ AC_INIT([staden],[2.0.0b11-2016])
 
 
 AC_CONFIG_HEADERS(staden_config.h)
+AC_CONFIG_MACRO_DIR([ac_stubs])
 
 #-
 # Checks for compiler programs.

staden: possibly undefined macro: AC_MSG_ERROR despite pkg-config was added to Build-Depends

[Andreas Tille]

Hi,

I tried to build staden[1] using debhelper 11 but I get

...
   dh_autoreconf
aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
configure.in:32: error: possibly undefined macro: AC_MSG_ERROR
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.in:33: error: possibly undefined macro: AC_MSG_WARN
autoreconf: /usr/bin/autoconf failed with exit status: 1
...

Since usually the solution is to add pkg-config to Build-Depends
I tried this but this does not change anything.  Any idea how to
fix this?

Kind regards

   Andreas.

[1] https://salsa.debian.org/med-team/staden

-- 
http://fam-tille.de

Re: build-depends for different distro releases

[Mattia Rizzolo]

On Fri, 2 Mar 2018, 10:54 p.m. Daniel Sperka,  wrote:

>It seems that under stretch, libvtk5 has been replaced by libvtk6, and
> libpng12 by libpng16.
>

This is the *very* reason for which -dev packages shouldn't contain the
soversion...


Given that you are using cowbuilder, which respects the alternative
build-dependencies, just put the all separated by |, in the meantime hoping
they will become unversioned in the future.

Re: build-depends for different distro releases

[Dan Kegel]

I put 'em all on separate lines so I can add comments;
my control tends to look like this for packages that build on multiple
versions of ubuntu:

Build-Depends: debhelper (>= 7),
# libpng12-dev for ubuntu 16.04, libpng-dev for ubuntu 17.10 and up
   libpng12-dev | libpng-dev,
   libvtk6-dev | libvtk5-dev,
...

It's a fragile approach, but works well enough here.  Sometimes I have
to add version
specifiers or depend on proxy packages just to test which platform.  Ugh.
- Dan

On Fri, Mar 2, 2018 at 1:53 PM, Daniel Sperka <djspe...@ucdavis.edu> wrote:
>I'm updating the packaging for a software package for debian and ubuntu
> (via neurodebian). The src package will build (using cowbuilder) under
> ubuntu xenial and debian jessie.
>
>Under stretch, the build fails while updating build-deps:
>
>  pbuilder-satisfydepends-dummy :
>  Depends: libvtk5-dev which is a virtual package and is not provided by
> any available package
>  Depends: libpng12-dev which is a virtual package and is not provided by
> any available package
>
>It seems that under stretch, libvtk5 has been replaced by libvtk6, and
> libpng12 by libpng16.
>
>How can I express this in a single control file? In other words, my
> control file has the following (which works under debian/jessie and
> ubuntu/xenial):
>
> Under xenial/jessie the following is in debian/control:
>
> Build-Depends: debhelper (>= 5), libqt4-dev (>= 4.3), libqt4-opengl-dev |
> libqt4-dev (<< 4.4.0), libqwt5-qt4-dev, libvtk5-dev, libminc-dev,
> libqtassistantclient-dev, libpng12-dev, cmake
>
> It seems that I need to have this line be different under debian/stretch:
>
> Under xenial/jessie the following is in debian/control:
>
> Build-Depends: debhelper (>= 5), libqt4-dev (>= 4.3), libqt4-opengl-dev |
> libqt4-dev (<< 4.4.0), libqwt5-qt4-dev, libvtk6-dev, libminc-dev,
> libqtassistantclient-dev, libpng16-dev, cmake
>
>
> Dan
>
>
>
>
>
> --
> Daniel J. Sperka, Ph. D.
> UC Davis Center for Neuroscience

build-depends for different distro releases

[Daniel Sperka]

   I'm updating the packaging for a software package for debian and ubuntu
(via neurodebian). The src package will build (using cowbuilder) under
ubuntu xenial and debian jessie.

   Under stretch, the build fails while updating build-deps:

 pbuilder-satisfydepends-dummy :
 Depends: libvtk5-dev which is a virtual package and is not provided by
any available package
 Depends: libpng12-dev which is a virtual package and is not provided
by any available package

   It seems that under stretch, libvtk5 has been replaced by libvtk6, and
libpng12 by libpng16.

   How can I express this in a single control file? In other words, my
control file has the following (which works under debian/jessie and
ubuntu/xenial):

Under xenial/jessie the following is in debian/control:

Build-Depends: debhelper (>= 5), libqt4-dev (>= 4.3), libqt4-opengl-dev |
libqt4-dev (<< 4.4.0), libqwt5-qt4-dev, libvtk5-dev, libminc-dev,
libqtassistantclient-dev, libpng12-dev, cmake

It seems that I need to have this line be different under debian/stretch:

Under xenial/jessie the following is in debian/control:

Build-Depends: debhelper (>= 5), libqt4-dev (>= 4.3), libqt4-opengl-dev |
libqt4-dev (<< 4.4.0), libqwt5-qt4-dev, libvtk6-dev, libminc-dev,
libqtassistantclient-dev, libpng16-dev, cmake


Dan





-- 
Daniel J. Sperka, Ph. D.
UC Davis Center for Neuroscience

Re: Cross-compiling a package that build-depends on Python

[Johannes Schauer]

Quoting Łukasz Walewski (2018-02-05 21:19:27)
> On 03.02.2018 14:23, Helmut Grohne wrote:
> > All Build-Depends are treated as host architecture by default. In this
> > case, it seems very likely that python is a build tool so you
> > (implicitly) requested python for the wrong architecture. Switching a
> > dependency from host architecture to build architecture happens by
> > annotating it with ":native" (<- only works in Build-Depends, not
> > Depends).
> This is exactly what I was looking for! I anticipated that there must a 
> way to enforce the native build architecture, but I could not find it 
> anywhere. Could you please point me to the respective documentation?

https://wiki.ubuntu.com/MultiarchCross

Unfortunately, documenting multiarch properly is hard. :(

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687900


signature.asc
Description: signature

Meta-packages ‘python-all’ and ‘python3-all’ (was: Cross-compiling a package that build-depends on Python)

[Ben Finney]

Łukasz Walewski  writes:

> BTW what is this python-all good for?

This expresses “whatever versions of Python 2 are currently supported in
the distribution”.

Similarly, ‘python3-all’ says the equivalent about Python 3 versions.

It is only contingent that, today, ‘python-all’ installs only Python 2.7
and ‘python3-all’ installs only Python 3.6. At other times, either of
those packages might install multiple versions.

It's true that, by current PSF policy, there will never be a Python 2.8.
Nevertheless, ‘python-all’ in the past (and ‘python3-all’ today)
expresses the meaning explained above.

See the Debian Python Policy for more; in particular,
.

-- 
 \   “I have one rule to live by: Don't make it worse.” —Hazel |
  `\  Woodcock |
_o__)  |
Ben Finney

Re: Cross-compiling a package that build-depends on Python

[Łukasz Walewski]

On 03.02.2018 14:23, Helmut Grohne wrote:

Recently the upstream development introduced a compile step that requires
some source files to be pre-processed with a Python script (shipped with the
sources). I thus added python-all to my Build-Depends field and the native

Why do you use python-all? If python is simply used as a build tool, you
don't need all versions of python. A single version should be
sufficient. Preferably, you use python3 here.


Well, probably I took the package description too literally:

"This package is a dependency package used as a build dependency for 
other packages to avoid hardcoded dependencies on specific Python runtimes."


Besides, it currently implies python2.7 only, but thanks, changed to 
explicit version now.


BTW what is this python-all good for?


The question to think about is: What do you need python for?
Often enough the answer is "it is executed during build, but the
resulting .deb does not integrate with python in any way". That answer
translates to "you want the build architecture python".

Yes, that's what I need.


All Build-Depends are treated as host architecture by default. In this
case, it seems very likely that python is a build tool so you
(implicitly) requested python for the wrong architecture. Switching a
dependency from host architecture to build architecture happens by
annotating it with ":native" (<- only works in Build-Depends, not
Depends).
This is exactly what I was looking for! I anticipated that there must a 
way to enforce the native build architecture, but I could not find it 
anywhere. Could you please point me to the respective documentation?



Practically, whenever you see python{,3}{,-all}{,-dev} in Build-Depends
you can already tell that your package won't cross build. Often times
annotating the dependency is correct, but for python-dev the fix often is
s/python3?\(-all\)?-dev/lib&, &:native/g instead.
Well, at least in my caste the annotation ":native" worked just fine! 
Thanks!


Best regards,
Lukasz

Re: Cross-compiling a package that build-depends on Python

[Helmut Grohne]

Hi,

thanks to pabs for making me aware of the question. I'm cross posting it
to d-cross@l.d.o as that is the proper place for these questions.

On Fri, Feb 02, 2018 at 02:01:30PM +0100, Lukasz Walewski wrote:
> I maintain a binary package that is not part of Debian (yet). The upstream
> content is developed for amd64 and armhf architectures and distributed using
> git. I build the package using git-buildpackage and pbuilder/pdebuild on an
> amd64 build machine with native (i.e. amd64) pbuilder. Obviously, when
> building for armhf, I am cross-compiling.

It's great to hear that cross compiling is starting to just work in some
contexts.

> Recently the upstream development introduced a compile step that requires
> some source files to be pre-processed with a Python script (shipped with the
> sources). I thus added python-all to my Build-Depends field and the native

Why do you use python-all? If python is simply used as a build tool, you
don't need all versions of python. A single version should be
sufficient. Preferably, you use python3 here.

> build works fine again. However, the cross-build doesn't work because the
> postinst script of the python-minimal:armhf package tries to execute the
> armhf python2.7 binary on my amd64 pbuilder:
> 
> $ pdebuild -- --host-arch armhf
> [...]
> Setting up python2.7-minimal:armhf (2.7.13-2+deb9u2) ...
> /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: Exec format error
> dpkg: error processing package python2.7-minimal:armhf (--configure):
>  subprocess installed post-installation script returned error exit status 2
> dpkg: dependency problems prevent configuration of python-minimal:armhf:
>  python-minimal:armhf depends on python2.7-minimal (>= 2.7.13-1~); however:
>   Package python2.7-minimal:armhf is not configured yet.
> 
> dpkg: error processing package python-minimal:armhf (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  python2.7-minimal:armhf
>  python-minimal:armhf
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> E: Failed to process build dependencies
> E: pbuilder-satisfydepends failed.

python is quite unique in this respect. Installing it requires executing
python and unlike perl it can be installed for foreign architectures in
theory. As you noticed, this doesn't work practically.

> What is the correct way of handling this scenario?

The question to think about is: What do you need python for?

Often enough the answer is "it is executed during build, but the
resulting .deb does not integrate with python in any way". That answer
translates to "you want the build architecture python". On the other
hand, if the resulting .deb ships a python extension, the answer
translates to "you want the host architecture python".

All Build-Depends are treated as host architecture by default. In this
case, it seems very likely that python is a build tool so you
(implicitly) requested python for the wrong architecture. Switching a
dependency from host architecture to build architecture happens by
annotating it with ":native" (<- only works in Build-Depends, not
Depends).

Practically, whenever you see python{,3}{,-all}{,-dev} in Build-Depends
you can already tell that your package won't cross build. Often times
annotating the dependency is correct, but for python-dev the fix often is
s/python3?\(-all\)?-dev/lib&, &:native/g instead.

I wonder whether we should turn this into a lintian warning. The
presented solution is somewhat incomplete. If you also list some python
module in Build-Depends, things become difficult and there is no
straight forward fix. Sometimes (e.g. python3-six) the module is marked
Multi-Arch: foreign and the approach keeps working, but for e.g.
python3-mako we already have no solution despite it being very common
(via gobject-introspection).

Hope this helps. If it doesn't, please continue at d-cross@l.d.o.

Helmut

Cross-compiling a package that build-depends on Python

[Lukasz Walewski]

Hi,

I maintain a binary package that is not part of Debian (yet). The 
upstream content is developed for amd64 and armhf architectures and 
distributed using git. I build the package using git-buildpackage and 
pbuilder/pdebuild on an amd64 build machine with native (i.e. amd64) 
pbuilder. Obviously, when building for armhf, I am cross-compiling.


Recently the upstream development introduced a compile step that 
requires some source files to be pre-processed with a Python script 
(shipped with the sources). I thus added python-all to my Build-Depends 
field and the native build works fine again. However, the cross-build 
doesn't work because the postinst script of the python-minimal:armhf 
package tries to execute the armhf python2.7 binary on my amd64 
pbuilder:


$ pdebuild -- --host-arch armhf
[...]
Setting up python2.7-minimal:armhf (2.7.13-2+deb9u2) ...
/var/lib/dpkg/info/python2.7-minimal.postinst: 42: 
/var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: Exec format 
error

dpkg: error processing package python2.7-minimal:armhf (--configure):
 subprocess installed post-installation script returned error exit 
status 2

dpkg: dependency problems prevent configuration of python-minimal:armhf:
 python-minimal:armhf depends on python2.7-minimal (>= 2.7.13-1~); 
however:

  Package python2.7-minimal:armhf is not configured yet.

dpkg: error processing package python-minimal:armhf (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python2.7-minimal:armhf
 python-minimal:armhf
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Failed to process build dependencies
E: pbuilder-satisfydepends failed.

What is the correct way of handling this scenario?

Thanks & best regards,
Lukasz

Re: Is there any sensible way to know what qt5 devel packages might be needed as build-depends

[Christian Seiler]

Hi Andreas,

Am 2017-09-26 17:41, schrieb Andreas Tille:

I try to port clonalframe[1] to Qt5 and I somehow wild-guessed what
Build-Depends might be needed.  Anyway I got

  qmake: could not find a Qt installation of ''

I've got this totally unhelpful message in another package - what
is a sensible approach to find the needed packages?


Since the project is using qmake as it's build system, you could
try:

find . -name "*.pro" -o -name "*.pri" -print0 | \
   xargs -0 grep -A 3 -E "QT.*="

to find all the lines of the type

QT += core gui widgets

and the such. Then you could go through those and see if there is
a "libqt5XXX5-dev" package (replace XXX with the module) available.
Some things are in qtbase5-dev directly (such as the 3 examples I
have above) though.

It could also be that some modules of Qt aren't packaged yet at
all. For example - and I may be mistaken about that - I don't
believe there's a libqt5datavisualization5-dev for that module in
Debian yet.

Regards,
Christian

Is there any sensible way to know what qt5 devel packages might be needed as build-depends

[Andreas Tille]

Hi,

I try to port clonalframe[1] to Qt5 and I somehow wild-guessed what
Build-Depends might be needed.  Anyway I got

  qmake: could not find a Qt installation of ''

I've got this totally unhelpful message in another package - what
is a sensible approach to find the needed packages?

Kind regards

 Andreas.

[1] https://anonscm.debian.org/git/debian-med/clonalframe.git

-- 
http://fam-tille.de

Re: Is there any chance to easily find out Qt5 Build-Depends (Was: Bug#874851: [clustalx] Future Qt4 removal from Buster)

[Andrey Rahmatullin]

On Mon, Sep 11, 2017 at 12:10:45PM +0200, Andreas Tille wrote:
> > That's not enough, you also need
> > export QT_SELECT=qt5
> +QT_SELECT=qt5
You've forgot "export".

> Assuming that I would get the error message above I also would have no
> idea how to deal with it.  As far as I can see QPushButton is moved to a
> different dir:
> 
> $ apt-file search QPushButton
> libqt4-dev: /usr/include/qt4/QtGui/QPushButton
> qtbase5-dev: /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QPushButton
Well, who said the software supports Qt5?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Is there any chance to easily find out Qt5 Build-Depends (Was: Bug#874851: [clustalx] Future Qt4 removal from Buster)

[gregor herrmann]

On Mon, 11 Sep 2017 12:10:45 +0200, Andreas Tille wrote:

> > After that you'll get better errors (the first one being "QPushButton: No
> > such file or directory").
> 
> Assuming that I would get the error message above I also would have no
> idea how to deal with it.  As far as I can see QPushButton is moved to a
> different dir:
> 
> $ apt-file search QPushButton
> libqt4-dev: /usr/include/qt4/QtGui/QPushButton
> qtbase5-dev: /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QPushButton
> 
> but according this it should be found with my provided Build-Depends.

Yes, but this needs code changes as well:

https://wiki.qt.io/Transition_from_Qt_4.x_to_Qt5#QtWidgets_as_a_Separate_Module


| Solution
| 
| Add this in your *.pro file:
| QT += widgets
| 
| Change all instances of
| #include 
| to
| #include 


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #166:  /pub/lunch 

Re: Is there any chance to easily find out Qt5 Build-Depends (Was: Bug#874851: [clustalx] Future Qt4 removal from Buster)

[Andreas Tille]

Hi Andrey,

On Mon, Sep 11, 2017 at 01:10:50PM +0500, Andrey Rahmatullin wrote:
> That's not enough, you also need
> export QT_SELECT=qt5

OK, so I did:

$ git diff
diff --git a/debian/rules b/debian/rules
index 75d1955..d4f697f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+QT_SELECT=qt5
+
 %:
dh $@


> After that you'll get better errors (the first one being "QPushButton: No
> such file or directory").

... but the situation is unchanged at my side in a pbuilder chroot.

Assuming that I would get the error message above I also would have no
idea how to deal with it.  As far as I can see QPushButton is moved to a
different dir:

$ apt-file search QPushButton
libqt4-dev: /usr/include/qt4/QtGui/QPushButton
qtbase5-dev: /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QPushButton

but according this it should be found with my provided Build-Depends.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Is there any chance to easily find out Qt5 Build-Depends (Was: Bug#874851: [clustalx] Future Qt4 removal from Buster)

[Andrey Rahmatullin]

On Mon, Sep 11, 2017 at 09:45:19AM +0200, Andreas Tille wrote:
> diff --git a/debian/rules b/debian/rules
> index e52b82f..75d1955 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -6,7 +6,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> dh $@
>  
>  override_dh_auto_configure:
> -   qmake-qt4
> +   qmake
> # did not found a better way to push hardening flags into Makefile
> sed -i -e "s:CFLAGS *= .*:& $(CFLAGS):" \
>-e "s:CXXFLAGS *= .*:& $(CXXFLAGS):" \
That's not enough, you also need
export QT_SELECT=qt5

After that you'll get better errors (the first one being "QPushButton: No
such file or directory").

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Is there any chance to easily find out Qt5 Build-Depends (Was: Bug#874851: [clustalx] Future Qt4 removal from Buster)

[Andreas Tille]

Hi,

I tried to port clustalx[1] to Qt5 by the following patch:

diff --git a/debian/control b/debian/control
index 569d145..efee27b 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,9 @@ Uploaders: Steffen Moeller <moel...@debian.org>,
 Section: science
 Priority: optional
 Build-Depends: debhelper (>= 9),
-   libqt4-dev
+   qtbase5-dev,
+   qtbase5-dev-tools,
+   qttools5-dev-tools
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/clustalx.git
 Vcs-Git: https://anonscm.debian.org/git/debian-med/clustalx.git
diff --git a/debian/rules b/debian/rules
index e52b82f..75d1955 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
dh $@
 
 override_dh_auto_configure:
-   qmake-qt4
+   qmake
# did not found a better way to push hardening flags into Makefile
sed -i -e "s:CFLAGS *= .*:& $(CFLAGS):" \
   -e "s:CXXFLAGS *= .*:& $(CXXFLAGS):" \

Unfortunately this ends up in:

  qmake: could not find a Qt installation of ''

and I admit this pretty useless error message seems to be a usual
pattern.  I wonder whether there is any better chance to find out
what Build-Depends is missing.

Kind regards

  Andreas.

[1] https://anonscm.debian.org/git/debian-med/clustalx.git

-- 
http://fam-tille.de

Re: build-depends on a _source_ package ?

[Benoît Rouits]

Thank you Christian for your clear explanation.
I think i only need the headers files, but i will check
this before to file a bug to the qtcreator package, so.

Thankfully,
 Benoît

Le 13/06/2017 à 08:54, Christian Seiler a écrit :

Hi,

On 06/12/2017 11:05 PM, Benoît Rouits wrote:

Is there a solution ? Should i file a bug on WNPP to ask for a
qtcreator-dev package in order to have qtcreator source installed in
/usr/src ?


Do you need the entire source of Qt Creator or just some header files?

In either case, you can only build-depend on binary packages, so that
you will need to ask the Qt Creator people to provide an additional
package for you.

If you only need header files, you should ask them to provide a
-dev package with the headers (and potentially .so libraries). If you
need the entire source tree, then you should ask them to provide a
-source package (see e.g. gcc-6-source, glibc-source, linux-source for
examples of this already in the archive) that puts the entire source
tree into /usr/src.

Note that you shouldn't open a bug on WNPP, but rather a bug on the
qtcreator package itself, severity wishlist, requesting this.

Hope that helps.

Regards,
Christian

Re: build-depends on a _source_ package ?

[Christian Seiler]

Hi,

On 06/12/2017 11:05 PM, Benoît Rouits wrote:
> Is there a solution ? Should i file a bug on WNPP to ask for a
> qtcreator-dev package in order to have qtcreator source installed in
> /usr/src ?

Do you need the entire source of Qt Creator or just some header files?

In either case, you can only build-depend on binary packages, so that
you will need to ask the Qt Creator people to provide an additional
package for you.

If you only need header files, you should ask them to provide a
-dev package with the headers (and potentially .so libraries). If you
need the entire source tree, then you should ask them to provide a
-source package (see e.g. gcc-6-source, glibc-source, linux-source for
examples of this already in the archive) that puts the entire source
tree into /usr/src.

Note that you shouldn't open a bug on WNPP, but rather a bug on the
qtcreator package itself, severity wishlist, requesting this.

Hope that helps.

Regards,
Christian

build-depends on a _source_ package ?

[Benoît Rouits]

Hello dear mentors,

This must be a frequently asked question over the years, sorry:

I built recently a binary package of a specific plugin for qtcreator,
on Debian Stretch, but this requires the source (package) of qtcreator
in order to build. As Debian Stretch has no qtcreator-dev, i had to
apt-get source qtcreator.

I don't know how to automate build dependency to a _source_ package,
since the -dev does not (or seems not to) exist, at least in
Stretch.

Is there a solution ? Should i file a bug on WNPP to ask for a
qtcreator-dev package in order to have qtcreator source installed in
/usr/src ?

Thank you for your advices,
 Benoît



signature.asc
Description: OpenPGP digital signature

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

[Sandro Tosi]

work is already in progress, no need to prod or write stuff like
"Don't do that." is not helping anyone

On Fri, Jan 20, 2017 at 3:31 PM, Andreas Tille <ti...@debian.org> wrote:
> [Sandro Tosi <mo...@debian.org> in CC]
>
> On Fri, Jan 20, 2017 at 11:05:44PM +0500, Andrey Rahmatullin wrote:
>> On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
>> > matplotlib build-depends on:
>> > - python3-mpltoolkits.basemap:arm64
>> > python3-mpltoolkits.basemap depends on:
>> > - python3-matplotlib:arm64
>> > python3-matplotlib depends on:
>> > - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
>> > matplotlib build-depends on:
>> > - python3-mpltoolkits.basemap:arm64
>> > python3-mpltoolkits.basemap depends on:
>> > - python3-matplotlib:arm64
>> > python-matplotlib-data conflicts with:
>> > - python3-matplotlib:arm64 (< 2.0.0)
>> So it looks like matplotlib transitively B-D on itself. And because the
>> maintainer uploaded the arch:all and arch:amd64 packages directly, no
>> architectures except amd64 have the same version of arch:all and arch:!all
>> subpackages.
>> Don't do that.
>
> Can this be fixed please?
>
> Thanks
>
>   Andreas.
>
> --
> http://fam-tille.de



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

[Andreas Tille]

[Sandro Tosi <mo...@debian.org> in CC]

On Fri, Jan 20, 2017 at 11:05:44PM +0500, Andrey Rahmatullin wrote:
> On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
> > matplotlib build-depends on:
> > - python3-mpltoolkits.basemap:arm64
> > python3-mpltoolkits.basemap depends on:
> > - python3-matplotlib:arm64
> > python3-matplotlib depends on:
> > - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
> > matplotlib build-depends on:
> > - python3-mpltoolkits.basemap:arm64
> > python3-mpltoolkits.basemap depends on:
> > - python3-matplotlib:arm64
> > python-matplotlib-data conflicts with:
> > - python3-matplotlib:arm64 (< 2.0.0)
> So it looks like matplotlib transitively B-D on itself. And because the
> maintainer uploaded the arch:all and arch:amd64 packages directly, no
> architectures except amd64 have the same version of arch:all and arch:!all
> subpackages.
> Don't do that.

Can this be fixed please?

Thanks

  Andreas.

-- 
http://fam-tille.de

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

[Andrey Rahmatullin]

On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
> matplotlib build-depends on:
> - python3-mpltoolkits.basemap:arm64
> python3-mpltoolkits.basemap depends on:
> - python3-matplotlib:arm64
> python3-matplotlib depends on:
> - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
> matplotlib build-depends on:
> - python3-mpltoolkits.basemap:arm64
> python3-mpltoolkits.basemap depends on:
> - python3-matplotlib:arm64
> python-matplotlib-data conflicts with:
> - python3-matplotlib:arm64 (< 2.0.0)
So it looks like matplotlib transitively B-D on itself. And because the
maintainer uploaded the arch:all and arch:amd64 packages directly, no
architectures except amd64 have the same version of arch:all and arch:!all
subpackages.
Don't do that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Build-Depends issue between matplotlib and basemap on anything but amd64

[Andreas Tille]

Hi,

I intend to update python-biopython but got BD-Uninstallable in the
build logs[1] for anything but amd64:

python-biopython build-depends on:
- python3-matplotlib:arm64
python3-matplotlib depends on:
- python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
python-biopython build-depends on:
- python3-matplotlib:arm64
python-matplotlib-data conflicts with:
- python3-matplotlib:arm64 (< 2.0.0)

Looking at matplotlib logs[2] it looks like:

matplotlib build-depends on:
- python3-mpltoolkits.basemap:arm64
python3-mpltoolkits.basemap depends on:
- python3-matplotlib:arm64
python3-matplotlib depends on:
- python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
matplotlib build-depends on:
- python3-mpltoolkits.basemap:arm64
python3-mpltoolkits.basemap depends on:
- python3-matplotlib:arm64
python-matplotlib-data conflicts with:
- python3-matplotlib:arm64 (< 2.0.0)


Since basemap seems fine I'm a bit confused what's wrong here and
how to fix this.

Kind regards

 Andreas.


[1] https://buildd.debian.org/status/package.php?p=python-biopython
[2] https://buildd.debian.org/status/package.php?p=matplotlib

-- 
http://fam-tille.de

Re: Build-Depends vs Depends

[Taylor Kline]

On Jan 3, 2017 9:33 PM, "Paul Wise" <p...@debian.org> wrote:

On Wed, Jan 4, 2017 at 1:52 AM, Taylor Kline wrote:

> Thanks, that does help a lot, and it helped me to realize that the
packages
> are built on the Debian machines and sent to users already built, so
there's
> no need for the users to install the Build-Depends, right?

Right, except users might want to build packages themselves, in that
case they would have to install the Build-Depends on the machine or
chroot where they are doing the building. There are several tools to
setup an isolated environment and install build-depends automatically.

https://wiki.debian.org/sbuild
https://wiki.debian.org/pbuilder
https://wiki.debian.org/cowbuilder
https://wiki.debian.org/qemubuilder
https://packages.debian.org/whalebuilder

There are a few reasons users might want to build packages:

Customising the packages for their needs.

Rebuilding packages against newer versions of dependencies.

Rebuilding packages for older Debian releases.

Verifying that the source corresponds to the binaries:

https://wiki.debian.org/ReproducibleBuilds

--
bye,
pabs

https://wiki.debian.org/PaulWise


Extremely helpful, Paul, thanks so much for clearing that up 

Re: Build-Depends vs Depends

[Paul Wise]

On Wed, Jan 4, 2017 at 1:52 AM, Taylor Kline wrote:

> Thanks, that does help a lot, and it helped me to realize that the packages
> are built on the Debian machines and sent to users already built, so there's
> no need for the users to install the Build-Depends, right?

Right, except users might want to build packages themselves, in that
case they would have to install the Build-Depends on the machine or
chroot where they are doing the building. There are several tools to
setup an isolated environment and install build-depends automatically.

https://wiki.debian.org/sbuild
https://wiki.debian.org/pbuilder
https://wiki.debian.org/cowbuilder
https://wiki.debian.org/qemubuilder
https://packages.debian.org/whalebuilder

There are a few reasons users might want to build packages:

Customising the packages for their needs.

Rebuilding packages against newer versions of dependencies.

Rebuilding packages for older Debian releases.

Verifying that the source corresponds to the binaries:

https://wiki.debian.org/ReproducibleBuilds

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends vs Depends

[Andrey Rahmatullin]

On Tue, Jan 03, 2017 at 12:52:26PM -0500, Taylor Kline wrote:
> Thanks, that does help a lot, and it helped me to realize that the packages
> are built on the Debian machines and sent to users already built, so
> there's no need for the users to install the Build-Depends, right?
Right.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Build-Depends vs Depends

[Taylor Kline]

On Jan 2, 2017 4:56 PM, "Octavio Alvarez" <octal...@alvarezp.org> wrote:

If you are using "apt install" then the packages under Build-Depends are
not installed at all, only those under Depends, and, because they are
needed for the program to work, those are not uninstalled after
installation.

If you are using "apt build-dep" then you are specifically requesting
APT to install packages lised under Build-Depends.

Hope this clarifies everything.

Best regards.


Thanks, that does help a lot, and it helped me to realize that the packages
are built on the Debian machines and sent to users already built, so
there's no need for the users to install the Build-Depends, right?

Re: Build-Depends vs Depends

[Taylor Kline]

On Jan 2, 2017 10:06 PM, "Paul Wise"  wrote:

You might be interested in looking at some of these diagrams to
discover more about how Debian works:

https://wiki.debian.org/Diagrams

You can look up any confusing jargon you find in this glossary:

https://wiki.debian.org/Glossary

--
bye,
pabs

https://wiki.debian.org/PaulWise


Very cool, thanks!

Re: Build-Depends vs Depends

[Paul Wise]

On Fri, Dec 30, 2016 at 12:31 PM, Taylor Kline wrote:

> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)

You might be interested in looking at some of these diagrams to
discover more about how Debian works:

https://wiki.debian.org/Diagrams

You can look up any confusing jargon you find in this glossary:

https://wiki.debian.org/Glossary

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends vs Depends

[Octavio Alvarez]

On 01/02/2017 06:06 AM, Taylor Kline wrote:
> Thank you, Octavio. Does this mean apt will temporarily install
> the Build-Depends packages and remove them after the installation
> completes?

If you are using "apt install" then the packages under Build-Depends are
not installed at all, only those under Depends, and, because they are
needed for the program to work, those are not uninstalled after
installation.

If you are using "apt build-dep" then you are specifically requesting
APT to install packages lised under Build-Depends.

Hope this clarifies everything.

Best regards.

Re: Build-Depends vs Depends

[Ben Finney]

Taylor Kline <taylor.kl...@utexas.edu> writes:

> Thank you, Octavio. Does this mean apt

You mean ‘dpkg’.

APT is a tool to fetch packages and to make requests to ‘dpkg’. It is
‘dpkg’'s job to do the actual install/remove of each individual package.

> will temporarily install the Build-Depends packages and remove them
> after the installation completes?

No.

The purpose of the build process is to generate a product that is ready
to install. The build dependencies are not needed after the build is
complete.

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\  so, Brain, but pantyhose are so uncomfortable in the |
_o__)  summertime.” —_Pinky and The Brain_ |
Ben Finney

Re: Build-Depends vs Depends

[Andrey Rahmatullin]

On Mon, Jan 02, 2017 at 09:06:10AM -0500, Taylor Kline wrote:
> Thank you, Octavio. Does this mean apt will temporarily install the
> Build-Depends
> packages and remove them after the installation completes?
apt doesn't build the package during install. Packages that you install
are already built.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Build-Depends vs Depends

[Taylor Kline]

Thank you, Octavio. Does this mean apt will temporarily install the
Build-Depends
packages and remove them after the installation completes?

Re: Build-Depends vs Depends

[Octavio Alvarez]

On 01/01/2017 04:07 PM, Ben Finney wrote:
> Taylor Kline <taylor.kl...@utexas.edu> writes:
> 
>> What is the difference [between the “Build-Depends” field and the
>> “Depends” field]?
> 
> The difference is precisely that between building the package from
> source, versus using the package installed.

For example, a compiler is needed during build time, but it's not needed
to run the program so it would qualify for Build-Depends but not
for Depends.

Build-Depends is used during "apt build-dep" (used for compilation and
building the package) and Depends is used during "apt install".

Best regards.


-- 
Octavio.

Re: Build-Depends vs Depends

[Ben Finney]

Taylor Kline <taylor.kl...@utexas.edu> writes:

> What is the difference [between the “Build-Depends” field and the
> “Depends” field]?

The difference is precisely that between building the package from
source, versus using the package installed.

The “Build-Depends” and “Build-Depends-Indep” fields appear only in the
source package stanza.

The “Depends” field appears only in a binary package stanza.

See Debian Polcy §5.2 for a summary, and §5 generally for a description
of what these fields mean.

> How are they treated differently during the apt installation process?

The installation process (the ‘dpkg’ tool does the actual installation
of an individual package) cares only about “Depends”, the declaration of
what other packages must be installed for this one to work.

The package build servers care about “Build-Depends” and
“Build-Depends-Indep”, because the job they're doing is not to use the
package but to build it from source.

-- 
 \ “Computers are useless. They can only give you answers.” —Pablo |
  `\   Picasso |
_o__)  |
Ben Finney

Re: Build-Depends vs Depends

[Narcis Garcia]

Build-Depends should not make any effect during package installation
process, because it's a dependency only for package-building process.



__
I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.
El 30/12/16 a les 05:31, Taylor Kline ha escrit:
> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)
> 

Re: Build-Depends vs Depends

[Harlan Lieberman-Berg]

Taylor Kline <taylor.kl...@utexas.edu> writes:
> What is the difference? How are they treated differently during the
> apt installation process? Thanks :)

Build-Depends is used only during build-time.  (Usually on the buildds,
though it can be on developer's computers as well.)

Depends, on the other hand, are packages that are required for the
package to /run/, and must be installed on the users' machines.

For certain packages that are interpreted, rather than compiled, these
are frequently the same list. (Think: python packages that don't have C
extensions).

Hope that makes sense!

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Build-Depends vs Depends

[Taylor Kline]

What is the difference? How are they treated differently during the
apt installation process? Thanks :)

Re: Build-Depends on source itself [libgap-sage]

[Bill Allombert]

On Wed, Nov 02, 2016 at 12:11:37PM +0800, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:
> 
> > Let give a try. I am dealing with the libgap-sage package [1].
> 
> Thanks for the extensive details.
> 
> > To begin with, GAP is a Computer Algebra System (CAS).
> > From an upstream point of view, libgap is not part of GAP itself.
> > libgap is rather a library wrapper for gap meant to get a better
> > access to the GAP kernel and to be used within Sage, which is a kind
> > a umbrella for multiple CAS (GAP, Singular, and a myriad of
> > scientific oriented software packages).
> > Note that, for now at least, GAP itself does not furnish any library; hence 
> > libgap.
> 
> The libgap project seems like a workaround for this bug in GAP?

This is not a bug in GAP. GAP has its own language and does not
provide a C interface. It also uses its own memory manager which is
not compatible with malloc.

Designing a library implies defining an API and an ABI, something that
has not been formalized for libgap.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Build-Depends on source itself [libgap-sage]

[Bill Allombert]

On Wed, Nov 02, 2016 at 03:22:41AM +, Jerome BENOIT wrote:
> Hello,
> 
> > On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
> >
> >> for one of my package, libgap-sage [1], the source material used for build
> >> is in fact seded meterial from an other package, gap: grossely the sed 
> >> process
> >> is the main part of libgap package: is there a standard way to use the 
> >> Debian
> >> source package of gap inside my own package libgap-sage ?
> >> Any hint or example is welcome.

Hello Jérome,
I was requested by Felix Salfelder to build gap-dev object files with
-fPIC for this purpose.
Instead of using sed, Sage should use a linker script, this would be
much cleaner.

gap (4r6p5-3) unstable; urgency=low

  * debian/rules:
   - build gap-dev object files with -fPIC to be compatible with use in
 shared libraries.

 -- Bill Allombert   Thu, 19 Sep 2013 15:00:06 +0200

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Build-Depends on source itself [libgap-sage]

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for your prompt reply.

On 02/11/16 04:11, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:
> 
>> Let give a try. I am dealing with the libgap-sage package [1].
> 
> Thanks for the extensive details.


You are welcome. 
> 
>> To begin with, GAP is a Computer Algebra System (CAS).
>> From an upstream point of view, libgap is not part of GAP itself.
>> libgap is rather a library wrapper for gap meant to get a better
>> access to the GAP kernel and to be used within Sage, which is a kind
>> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific 
>> oriented software packages).
>> Note that, for now at least, GAP itself does not furnish any library; hence 
>> libgap.
> 
> The libgap project seems like a workaround for this bug in GAP?

Indeed.

> 
>> Basically libgap adds a prefix to the GAP functions and variables,
>> and gather them in a library. We must have in mind the following points:
>> 1] The libgap source ball provides the modified source files with some delay
>> (current modified gap version in libgap is 4.8.3 while the current gap 
>> version is 4.8.5 ,
>> this version being the one in Stretch. In any case, the copyright headers of 
>> the source files
>> are not modified, so they cannot be packaged for copyright reasons.
> 
> That seems like a very suboptimal way to do it.

I guess that everybody is agree here.

> 
>> 2] The scripts that modify the original GAP source files is not distributed 
>> within
>> the libgap upstream source ball, but it is available via the libgap git 
>> repository [2] at Bitbucket
>> along some documentation for generating our own modified GAP source code. 
>> The current Debian source ball
>> for libgap is the git repository material (which unmodified contains but 
>> obsolete GAP material, version 4.8.3).
> 
> Ok, I'm glad this is not a DFSG violation. It could easily have been one.

I took care about this part of the story.

> 
>> 3] The libgap Debian package must be synchronized with the GAP Debian 
>> package, so modifying the (potentially)
>> patched GAP src/ is certainly not only a good idea but also a factor of 
>> stability and good maintenance.
> 
> Agreed.
> 
>> 4] Just the material in the subfolder src/ within the GAP source ball is 
>> needed, that is to say, not the all
>> source ball.
> 
> Makes sense.
> 
>> 5] We want a long term solution to ease the maintenance of Sage[Math] and 
>> its friends.
> 
> It seems clear to me that the only sane long-term solution is for GAP
> upstream to add a proper shared library.

Absolutely agree. My understanding is that the GAP upstream team is working on 
it.
But GAP is an heavy machinery, and  it might be not one of the top priorities.


 Has this been discussed with
> them at all?

I bet we can find long discussion about on the internet.

 Until GAP upstream are willing to do this,

Let focus on this part.


 I suggest one
> of the following:
> 
> Drop the libgap-sage source package entirely and add a secondary
> tarball to the Debian GAP source package containing only the libgap
> scripts and have the Debian build process for GAP use those scripts to
> create libgap-sage dev and lib binary packages. dpkg-source format v3
> can have multiple tarballs, which makes this doable sanely.
>

Keeping the `intersection' with the GAP debian package minimal is also a factor.

 
> OR
> 
> Get the GAP sources removed from the Bitbucket repository.
> 
> Have the build scripts in the libgap Bitbucket repository:
> 
> 1. require info on which source tree to copy or which version to download
> 2. copy that source tree or download that version
> 3. modify the local copy using the scripts as per normal
> 4. build the scripts as per normal
> 
> There might need to be some checking of the copied source tree to make
> sure the scripts still support it.

The current scheme of the libgap-sage package tends to this solution:
the first priority was to bring libga[-sage] to Debian.


> 
> Create a gap-libgap-sage-source (or similar) package from the GAP
> Debian package, containing the GAP src/ directory somewhere under
> /usr/src.
> 
> Have the libgap-sage package build-depend on gap-libgap-sage-source
> and point the libgap scripts at the GAP src/ directory under /usr/src.
> 
> Make sure that the libgap-sage package is binNMUed or rebuilt after
> every gap upload. I expect the script will need to change reasonably
> often due to changes in GAP though.

This is what I had in mind after reading your previous emails and the one of 
Den.

@Bill :
Which solution would you like to favour ?

Personally I prefer the second solution as it treats the GAP material as raw 
material
and that it puts a clear line between GAP and Sage as concerns Debian 
maintenance.

Can I start to write patch against the GAP debian/ material ?

Thanks,
Jerome

> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net

Re: Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> 2] The scripts that modify the original GAP source files is not distributed 
> within
> the libgap upstream source ball, but it is available via the libgap git 
> repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The 
> current Debian source ball
> for libgap is the git repository material (which unmodified contains but 
> obsolete GAP material, version 4.8.3).

One thing I just noticed: Please get libgap upstream to use the Python
subprocess module with shell=False instead of os.system, which is
deprecated and vulnerable to shell meta-character injection.

https://sources.debian.net/src/libgap-sage/4.8.3%2Bg69a66f0%2Bdsx-1/scripts/libGAPify.py/#L465

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> Let give a try. I am dealing with the libgap-sage package [1].

Thanks for the extensive details.

> To begin with, GAP is a Computer Algebra System (CAS).
> From an upstream point of view, libgap is not part of GAP itself.
> libgap is rather a library wrapper for gap meant to get a better
> access to the GAP kernel and to be used within Sage, which is a kind
> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific 
> oriented software packages).
> Note that, for now at least, GAP itself does not furnish any library; hence 
> libgap.

The libgap project seems like a workaround for this bug in GAP?

> Basically libgap adds a prefix to the GAP functions and variables,
> and gather them in a library. We must have in mind the following points:
> 1] The libgap source ball provides the modified source files with some delay
> (current modified gap version in libgap is 4.8.3 while the current gap 
> version is 4.8.5 ,
> this version being the one in Stretch. In any case, the copyright headers of 
> the source files
> are not modified, so they cannot be packaged for copyright reasons.

That seems like a very suboptimal way to do it.

> 2] The scripts that modify the original GAP source files is not distributed 
> within
> the libgap upstream source ball, but it is available via the libgap git 
> repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The 
> current Debian source ball
> for libgap is the git repository material (which unmodified contains but 
> obsolete GAP material, version 4.8.3).

Ok, I'm glad this is not a DFSG violation. It could easily have been one.

> 3] The libgap Debian package must be synchronized with the GAP Debian 
> package, so modifying the (potentially)
> patched GAP src/ is certainly not only a good idea but also a factor of 
> stability and good maintenance.

Agreed.

> 4] Just the material in the subfolder src/ within the GAP source ball is 
> needed, that is to say, not the all
> source ball.

Makes sense.

> 5] We want a long term solution to ease the maintenance of Sage[Math] and its 
> friends.

It seems clear to me that the only sane long-term solution is for GAP
upstream to add a proper shared library. Has this been discussed with
them at all? Until GAP upstream are willing to do this, I suggest one
of the following:

Drop the libgap-sage source package entirely and add a secondary
tarball to the Debian GAP source package containing only the libgap
scripts and have the Debian build process for GAP use those scripts to
create libgap-sage dev and lib binary packages. dpkg-source format v3
can have multiple tarballs, which makes this doable sanely.

OR

Get the GAP sources removed from the Bitbucket repository.

Have the build scripts in the libgap Bitbucket repository:

1. require info on which source tree to copy or which version to download
2. copy that source tree or download that version
3. modify the local copy using the scripts as per normal
4. build the scripts as per normal

There might need to be some checking of the copied source tree to make
sure the scripts still support it.

Create a gap-libgap-sage-source (or similar) package from the GAP
Debian package, containing the GAP src/ directory somewhere under
/usr/src.

Have the libgap-sage package build-depend on gap-libgap-sage-source
and point the libgap scripts at the GAP src/ directory under /usr/src.

Make sure that the libgap-sage package is binNMUed or rebuilt after
every gap upload. I expect the script will need to change reasonably
often due to changes in GAP though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself [libgap-sage]

[Jerome BENOIT]

Hello,


On 01/11/16 05:19, Paul Wise wrote:
> On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
>
>> for one of my package, libgap-sage [1], the source material used for build
>> is in fact seded meterial from an other package, gap: grossely the sed 
>> process
>> is the main part of libgap package: is there a standard way to use the Debian
>> source package of gap inside my own package libgap-sage ?
>> Any hint or example is welcome.
>
> At this time there is no way for source packages to build-depend on
> other source packages.
>
> The most often used workaround for this is binary packages with
> -source at the end of their names:
>
> $ aptitude search -- -source$


On 01/11/16 17:47, Paul Wise wrote:
> On Wed, Nov 2, 2016 at 12:38 AM, Jerome BENOIT wrote:
> 
>> Is there any guidance for such source packages ? Which ones of them I may 
>> consider
>> a good example.
> 
> They are all about the same, ship the source under /usr/src, done.
> 
>> I guess it is the best way to proceed.
> 
> It is probably the least good way to proceed, please provide some
> details so we can discuss a proper solution.
> 

Let give a try. I am dealing with the libgap-sage package [1].

To begin with, GAP is a Computer Algebra System (CAS).
>From an upstream point of view, libgap is not part of GAP itself.
libgap is rather a library wrapper for gap meant to get a better
access to the GAP kernel and to be used within Sage, which is a kind
a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific oriented 
software packages).
Note that, for now at least, GAP itself does not furnish any library; hence 
libgap.

Basically libgap adds a prefix to the GAP functions and variables,
and gather them in a library. We must have in mind the following points:
1] The libgap source ball provides the modified source files with some delay
(current modified gap version in libgap is 4.8.3 while the current gap version 
is 4.8.5 ,
this version being the one in Stretch. In any case, the copyright headers of 
the source files
are not modified, so they cannot be packaged for copyright reasons.
2] The scripts that modify the original GAP source files is not distributed 
within
the libgap upstream source ball, but it is available via the libgap git 
repository [2] at Bitbucket
along some documentation for generating our own modified GAP source code. The 
current Debian source ball
for libgap is the git repository material (which unmodified contains but 
obsolete GAP material, version 4.8.3).
3] The libgap Debian package must be synchronized with the GAP Debian package, 
so modifying the (potentially)
patched GAP src/ is certainly not only a good idea but also a factor of 
stability and good maintenance.
4] Just the material in the subfolder src/ within the GAP source ball is 
needed, that is to say, not the all
source ball.
5] We want a long term solution to ease the maintenance of Sage[Math] and its 
friends.

For now, instead of a full source package and as suggested by Ben Finney, I 
think that a pure technical package
that would contain main the src/ subfolder material is the best option.
Of course, I am willing to write the patch against the GAP debian/ material 
that will introduce this src package.
And, before all, it must be done with the agreement of the GAP Debian package 
maintainer.

Thanks,
Jerome


[1] https://packages.qa.debian.org/libg/libgap-sage.html
[2] https://bitbucket.org/vbraun/libgap

Re: Build-Depends on source itself

[Ben Finney]

Jerome BENOIT <calcu...@rezozer.net> writes:

> for one of my package, libgap-sage [1], the source material used for build
> is in fact seded meterial from an other package, gap

One good solution would be to have the ‘gap’ package build a new binary
package, maybe ‘gap-data’, that contains the data you need in a format
likely to be useful for many purposes.

Could you work with the ‘gap’ package maintainer to achieve that?

Once ‘gap-data’ (if that is the name the ‘gap’ maintainers decide)
exists, your poposed pacakge can “Build-Depends: gap-data” and work
forward from there.

-- 
 \   “Don't worry about what anybody else is going to do. The best |
  `\ way to predict the future is to invent it.” —Alan Kay |
_o__)  |
Ben Finney

Re: Build-Depends on source itself

[Paul Wise]

On Wed, Nov 2, 2016 at 12:38 AM, Jerome BENOIT wrote:

> Is there any guidance for such source packages ? Which ones of them I may 
> consider
> a good example.

They are all about the same, ship the source under /usr/src, done.

> I guess it is the best way to proceed.

It is probably the least good way to proceed, please provide some
details so we can discuss a proper solution.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Build-Depends on source itself

[Jerome BENOIT]

Hello, thanks for the quick reply.

On 01/11/16 05:19, Paul Wise wrote:
> On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:
> 
>> for one of my package, libgap-sage [1], the source material used for build
>> is in fact seded meterial from an other package, gap: grossely the sed 
>> process
>> is the main part of libgap package: is there a standard way to use the Debian
>> source package of gap inside my own package libgap-sage ?
>> Any hint or example is welcome.
> 
> At this time there is no way for source packages to build-depend on
> other source packages.
> 
> The most often used workaround for this is binary packages with
> -source at the end of their names:
> 
> $ aptitude search -- -source$

Is there any guidance for such source packages ? Which ones of them I may 
consider
a good example.


> 
> If you can provide some details about your situation, we can probably
> find a better solution.
> 

I guess it is the best way to proceed.

Thanks,
Jerome

Build-Depends on source itself

[Jerome BENOIT]

Dear mentors,

for one of my package, libgap-sage [1], the source material used for build
is in fact seded meterial from an other package, gap: grossely the sed process
is the main part of libgap package: is there a standard way to use the Debian
source package of gap inside my own package libgap-sage ?
Any hint or example is welcome.

Thanks in advance,
Jerome


[1] https://packages.qa.debian.org/libg/libgap-sage.html
-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

Re: Build-Depends on source itself

[Paul Wise]

On Tue, Nov 1, 2016 at 12:43 PM, Jerome BENOIT wrote:

> for one of my package, libgap-sage [1], the source material used for build
> is in fact seded meterial from an other package, gap: grossely the sed process
> is the main part of libgap package: is there a standard way to use the Debian
> source package of gap inside my own package libgap-sage ?
> Any hint or example is welcome.

At this time there is no way for source packages to build-depend on
other source packages.

The most often used workaround for this is binary packages with
-source at the end of their names:

$ aptitude search -- -source$

If you can provide some details about your situation, we can probably
find a better solution.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Build-Depends on source itself

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

for one of my package, libgap-sage [1], the source material used for build
is in fact seded meterial from an other package, gap: grossely the sed process
is the main part of libgap package: is there a standard way to use the Debian
source package of gap inside my own package libgap-sage ?
Any hint or example is welcome.

Thanks in advance,
Jerome

 
[1] https://packages.qa.debian.org/libg/libgap-sage.html
- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYGB1rAAoJED+SGaZ/NsaL+TUgALx4hUZVrTaZELF6szZXMunC
kFDTosjret1CmpDtNzaxeqpgvbc4csca/a9KUqd8ryigSmwEATN9dd6bZs+aE8Xn
sw8Xuk1yqf91AW76z87pVnX0FBuBKdaSKJpQGqgOa/uiNZ/iw7QBUAawhMeTNGPr
iOvRbqPp36c5pmEZI92Oc0nKpxrXfAKclbwXd/Neqpbb/LoRlxiBhau3KXJRQuwa
CCFLm783c8RqImeJnRCnFTB2VsqGO2fRLxR6+x0xyYQxKY4EZn6yD6adQQf8PUT3
t+z+P89JrFqwCAZrn8Sxg5BuQ1azF3lEoVxPr30GrWjoK6T3tNblYtSRrnmPJsNT
vR4QN7RKClfH2dqgDDmqKRlOsjtYchY7TxjdY6gl4vKxAoj1yEy4NTC3H5VLww54
aj1hBacYXVaEHvxKC0ojiLd7TLUbWv5/rmUp+mGsTaKEN5RD7pf4WrCr9dWuZM/6
QHG8Tz/xxAfYXeVmDccJfKzqg7N+/vKpUOnmRceMInatXEnhMeqz6r/XMktlFDNg
jINVvS2Gc/Z17bzK/4vZSGFR7/UhRzW3nE/uG2hN9fSlSLsv5qQ96wHnuIslBmtM
gyRaHRK7GPo7rptbQ6fuGgX6ZS13LZGNBRALgw8+sDp/M4ju5wOKWhb0sXUDjSk/
3JuzWmToUdUjMisbiqyo0G53Na0Eoy6ZLjO7Q6l4KGdfm+EiSN/To3LN/b9pLH0M
hi92CPMVuzm72cpdwgAArmRTJoIcuvG5r9e73PdTqoOd+IEgqNCd2THrGFixsOVp
ZXTJ8O49Vi9q8cpQM8MCUH1GR4TMBNCSns604Tv+DJgj/GQQ9TBGv3crR80b7bNo
4QTllXYAkZDDu/c2YDQV31bni36ivVQmfmHpiFkAkdjsNXNlMxWKPBijrIo/+Xmz
rjcPlmiDWzZDMlfPvM6r+TOOUnDCaV9VkYnVWdu72hWp4Sr0IlDnp34I5wHuWQWP
ECMSFoUh84MaD3DK8hRfhU7ORMDEPOCNPfo/lg/kwzYtfxxt99berq6NrvSy57j9
LoRyShy09n44gKkd5gKvp31Ir55da3vXuMu+PI6q+9aMY4mpGm8HPMu0fta8MvCb
fv6Eth7bni1ITcm4B8EmjqZdY7ahRxZJs51zLky8B9AssFW8BOP0eRai6a2v0OiO
dNSO+fZryRn+pqEWwho5XuVyqPeI3qq2AOrAdWqcMuWgY8iFuqRwzXimDp5+voI+
jrmdTvTSU+/1noanBHgHYbv7HUgzc3YEpLyA0RVcQv41NshIICFLPeLU7H3Jv5/v
ebTpp4oqyLVXKLjnACqcukiPWM9D4P7DEGSj7ZmXRpBJzg535CAFzAGylmNs2BQ=
=Xt8K
-END PGP SIGNATURE-

Re: Pbuilder requests Build-Depends on local machine - why this?

[Hideki Yamane]

Hi,

 It'd be better to give pbuilder more love :)
 # Probably Junichi is too busy to take care of his children and work.

On Fri, 26 Jun 2015 14:58:57 +
Mattia Rizzolo mat...@mapreri.org wrote:
 (btw it's not needed a local build, `vim /usr/bin/pdebuild` is enough :P)

 of course, I did so ;)

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150628164847.5af678b34d33b07176fc8...@debian.or.jp

Re: Pbuilder requests Build-Depends on local machine - why this?

[Mattia Rizzolo]

Hi *,

On Thu, Jun 25, 2015 at 10:02:32PM +0200, Andreas Tille wrote:
 On Thu, Jun 25, 2015 at 10:35:49PM +0900, Hideki Yamane wrote:
  
   I've changed local pdebuild as
  
  -echo dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} 
  $DEBBUILDOPTS | \ 
  +echo dpkg-buildpackage -S -d -us -uc -r${BUILDSOURCEROOTCMD} 
  $DEBBUILDOPTS | \
 
 Cool.  Do you intend to upload soonish or should rather I use a local
 build incorporating this meanwhile?

just FTR, I plan (and working towards) to adopt pbuilder, which is unmaintained
since some time.

I incorporated this particular change in my git clone, but another upload (NMU)
is already in deferred and will lend in 6 days in unstable.

I scheduled my upload as a maintainer with this somewhere mid/late july.
If that bugs you too much and you're willing to do un upload before please get
in touch with me and NMU pbuilder after the pending upload hits unstable.


(btw it's not needed a local build, `vim /usr/bin/pdebuild` is enough :P)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540 .''`.
more about me:  http://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-


signature.asc
Description: Digital signature

Re: Pbuilder requests Build-Depends on local machine - why this?

[Andreas Tille]

On Thu, Jun 25, 2015 at 10:35:49PM +0900, Hideki Yamane wrote:
 
  I've changed local pdebuild as
 
 -echo dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} 
 $DEBBUILDOPTS | \ 
 +echo dpkg-buildpackage -S -d -us -uc -r${BUILDSOURCEROOTCMD} 
 $DEBBUILDOPTS | \

Cool.  Do you intend to upload soonish or should rather I use a local
build incorporating this meanwhile?

Thanks for your work on pbuilder

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150625200232.gb13...@an3as.eu

Re: Pbuilder requests Build-Depends on local machine - why this?

[Sebastiaan Couwenberg]

 since I'm back from vacation and upgraded my testing system I realised
 that when using pbuilder the Build-Depends of some package seem to be
 required also on the machine that is creating the pbuilder chroot
 (=where you start pdebuild).  I regard this a bug but may be I'm missing
 something so before creating noise I would like to make sure whether its
 just me ...

This is usually because those build dependencies are required to run the
clean target that is execute first outside the chroot.

Kind Regards,

Bas


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/4d2e562e87d562d740e50ea359e135e7.squir...@webmail.xs4all.nl

Re: Pbuilder requests Build-Depends on local machine - why this?

[gregor herrmann]

On Thu, 25 Jun 2015 14:57:18 +0200, Andreas Tille wrote:

 since I'm back from vacation and upgraded my testing system I realised
 that when using pbuilder the Build-Depends of some package seem to be
 required also on the machine that is creating the pbuilder chroot
 (=where you start pdebuild).  

That's a change in dpkg-buildpackage:

From https://tracker.debian.org/news/685447 :

dpkg (1.18.0) unstable; urgency=low
[..]
  * Make dependency checks fatal for dpkg-buildpackage -S.


So you have to pass -d (for making the checks non-fatal, i.e.
warnings, again, as they were before), or -nc (don't run clean) to
dpkg-buildpackage; directly or via --debbuildopts in the case of
pdebuild.

(Note that -nc seems to break pbuilder's build twice feature.)


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #297:  Too many interrupts 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150625131433.ge28...@colleen.colgarra.priv.at

Pbuilder requests Build-Depends on local machine - why this?

[Andreas Tille]

Hi,

since I'm back from vacation and upgraded my testing system I realised
that when using pbuilder the Build-Depends of some package seem to be
required also on the machine that is creating the pbuilder chroot
(=where you start pdebuild).  I regard this a bug but may be I'm missing
something so before creating noise I would like to make sure whether its
just me ...

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150625125718.ga7...@an3as.eu

Re: Pbuilder requests Build-Depends on local machine - why this?

[Hideki Yamane]

 Hm, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786690

On Thu, 25 Jun 2015 15:14:33 +0200
gregor herrmann gre...@debian.org wrote:
 So you have to pass -d (for making the checks non-fatal, i.e.
 warnings, again, as they were before), or -nc (don't run clean) to
 dpkg-buildpackage; directly or via --debbuildopts in the case of
 pdebuild.
 
 (Note that -nc seems to break pbuilder's build twice feature.)

 I've changed local pdebuild as

-echo dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} $DEBBUILDOPTS 
| \ 
+echo dpkg-buildpackage -S -d -us -uc -r${BUILDSOURCEROOTCMD} 
$DEBBUILDOPTS | \


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150625223549.3832db1197d6b2c2ffd78...@debian.or.jp

Re: Pbuilder requests Build-Depends on local machine - why this?

[gregor herrmann]

On Thu, 25 Jun 2015 22:35:49 +0900, Hideki Yamane wrote:

  Hm, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786690

Thanks!
 
 On Thu, 25 Jun 2015 15:14:33 +0200
 gregor herrmann gre...@debian.org wrote:
  So you have to pass -d (for making the checks non-fatal, i.e.
  warnings, again, as they were before), or -nc (don't run clean) to
  dpkg-buildpackage; directly or via --debbuildopts in the case of
  pdebuild.
  
  (Note that -nc seems to break pbuilder's build twice feature.)
 
  I've changed local pdebuild as
 
 -echo dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} 
 $DEBBUILDOPTS | \ 
 +echo dpkg-buildpackage -S -d -us -uc -r${BUILDSOURCEROOTCMD} 
 $DEBBUILDOPTS | \

Ack, this possible patch for pdebuild also came to my mind later :)


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Joan Baez: The Boxer


signature.asc
Description: Digital Signature

Re: How to solve a FTBFS caused by Build-Depends being removed from the archive?

[Andrey Rahmatullin]

On Sat, Nov 15, 2014 at 05:51:06PM -0800, Cameron Norman wrote:
 The bug in question is here:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768671
 
 jenkins build depends on libjson-java, a package that was removed due
 to being suspected of containing non-free code (the JSON For good,
 not evil stuff), however it turned out that libjson-java was never
 actually affected by that
 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721072).
 
 Still, the package (libjson-java) was removed from Jessie.
 
 How can this bug in Jenkins be resolved (keeping it in Jessie)?
Only by dropping the dependency if it's possible.

 Can packages like libjson-java in sid migrate to jessie after the
 freeze in situations like this? 
According to https://release.debian.org/jessie/freeze_policy.html no.

 Or does jenkins not have any chance to be in jessie?
You can always ask the release team if they can make an exception to their
rules.


-- 
WBR, wRAR


signature.asc
Description: Digital signature

How to solve a FTBFS caused by Build-Depends being removed from the archive?

[Cameron Norman]

Hello,

The bug in question is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768671

jenkins build depends on libjson-java, a package that was removed due
to being suspected of containing non-free code (the JSON For good,
not evil stuff), however it turned out that libjson-java was never
actually affected by that
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721072).

Still, the package (libjson-java) was removed from Jessie.

How can this bug in Jenkins be resolved (keeping it in Jessie)?

Can packages like libjson-java in sid migrate to jessie after the
freeze in situations like this? Or does jenkins not have any chance to
be in jessie?

Thank you,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+3XCw_Z=2ofcy40nlhaf38fwpgknlsfmqimg3hjux...@mail.gmail.com

Re: How to solve a FTBFS caused by Build-Depends being removed from the archive?

[Vincent Cheng]

Hi,

On Sat, Nov 15, 2014 at 5:51 PM, Cameron Norman
camerontnor...@gmail.com wrote:

 Can packages like libjson-java in sid migrate to jessie after the
 freeze in situations like this? Or does jenkins not have any chance to
 be in jessie?

This is a question for the release team (debian-release@l.d.o), not
debian-mentors.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tBE9R-Tx0=qantw04hm6hgpju4xtootcjeg+cvjzhh...@mail.gmail.com

Re: How to solve a FTBFS caused by Build-Depends being removed from the archive?

[Cameron Norman]

El sáb, 15 de nov 2014 a las 5:56 , Vincent Cheng vch...@debian.org 
escribió:

Hi,

On Sat, Nov 15, 2014 at 5:51 PM, Cameron Norman
camerontnor...@gmail.com wrote:


 Can packages like libjson-java in sid migrate to jessie after the
 freeze in situations like this? Or does jenkins not have any chance 
to

 be in jessie?


This is a question for the release team (debian-release@l.d.o), not
debian-mentors.


So would I email -release asking for libjson-java to be migrated to 
jessie, or would I just use the exact message I posted here?


Regards,
--
Cameron Norman

Re: How to solve a FTBFS caused by Build-Depends being removed from the archive?

[Vincent Cheng]

On Sat, Nov 15, 2014 at 6:24 PM, Cameron Norman
camerontnor...@gmail.com wrote:
 El sáb, 15 de nov 2014 a las 5:56 , Vincent Cheng vch...@debian.org
 escribió:

 Hi, On Sat, Nov 15, 2014 at 5:51 PM, Cameron Norman
 camerontnor...@gmail.com wrote:

 Can packages like libjson-java in sid migrate to jessie after the freeze in
 situations like this? Or does jenkins not have any chance to be in jessie?

 This is a question for the release team (debian-release@l.d.o), not
 debian-mentors.


 So would I email -release asking for libjson-java to be migrated to jessie,
 or would I just use the exact message I posted here?

If you want a specific package to be unblocked, file an unblock
request; how to do so, and when it's appropriate, is explained in the
freeze policy [1]. If you have any other questions that relate to the
release team's responsibilities, you can ask either on their mailing
list or IRC channel (#debian-release on oftc).

Regards,
Vincent

[1] https://release.debian.org/jessie/freeze_policy.html


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tCs1ON1o+r=gKVdkSC=3=7skxwhsvj3uwayppgp_tg...@mail.gmail.com

Re: Which targets need their requirements in “Build-Depends*” declared?

[Jakub Wilk]

* Ben Finney ben+deb...@benfinney.id.au, 2013-12-16, 16:10:

Policy §7.7 says:

   Source packages that require certain binary packages to be installed
   or absent at the time of building the package can declare
   relationships to those binary packages.

   This is done using the `Build-Depends', `Build-Depends-Indep',
   `Build-Conflicts' and `Build-Conflicts-Indep' control fields.

What standard targets does this “at the time of building the package” 
entail?


These targets are listed in the last paragraphs of §7.7:
clean, build-arch, and binary-arch;
build, build-indep, binary, and binary-indep.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131218123630.ga9...@jwilk.net

Which targets need their requirements in “Build-Depends*” declared?

[Ben Finney]

Howdy all,

Which of the standard ‘debian/rules’ targets need their requirements
declared in “Build-Depends” (and “Build-Depends-Indep”)?

Policy §7.7 says:

Source packages that require certain binary packages to be installed
or absent at the time of building the package can declare
relationships to those binary packages.

This is done using the `Build-Depends', `Build-Depends-Indep',
`Build-Conflicts' and `Build-Conflicts-Indep' control fields.

What standard targets does this “at the time of building the package”
entail? The “test” target? The “get-orig-source” target? What official
set of standard targets obligate their requirements to be declared in
this field?

Note that I'm not looking for opinions about what would be a good idea;
I'm looking for how this policy section is interpreted for normative
behaviour.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but there's still a bug stuck in here from last time.” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/7w61qpjs8g@benfinney.id.au

Re: Which targets need their requirements in “Build-Depends*” declared?

[Russ Allbery]

Ben Finney ben+deb...@benfinney.id.au writes:

 Which of the standard ‘debian/rules’ targets need their requirements
 declared in “Build-Depends” (and “Build-Depends-Indep”)?

 Policy §7.7 says:

 Source packages that require certain binary packages to be installed
 or absent at the time of building the package can declare
 relationships to those binary packages.

 This is done using the `Build-Depends', `Build-Depends-Indep',
 `Build-Conflicts' and `Build-Conflicts-Indep' control fields.

 What standard targets does this “at the time of building the package”
 entail? The “test” target? The “get-orig-source” target? What official
 set of standard targets obligate their requirements to be declared in
 this field?

 Note that I'm not looking for opinions about what would be a good idea;
 I'm looking for how this policy section is interpreted for normative
 behaviour.

What's currently done everywhere in the archive is that the targets run by
dpkg-buildpackage (either arch or arch-indep builds) must have their
dependencies listed, and dependencies for the other targets are not
listed.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9g11h02@windlord.stanford.edu

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote:
  Maybe I've picked the wrong example, the actual problem was with
  libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
  but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
  my binary ended up importing either libavcodec53 and libavcodec54 when
  both were installed and did not work.
 If this is true, and I must say I may have had the same experience,
 isn't this hinting at a bug in libavdevice53, not being stable enough to
 keep the same SONAME? I think you should file a bug against libavdevice53.
Why? The problem is caused by indirect dependency on both libavcodec53 and
libavcodec54, not by ABI breakage.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Paul Gevers]

Hi Andrey,

On 21-03-13 07:46, Andrey Rahmatullin wrote:
 On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.
 If this is true, and I must say I may have had the same experience,
 isn't this hinting at a bug in libavdevice53, not being stable enough to
 keep the same SONAME? I think you should file a bug against libavdevice53.
 Why? The problem is caused by indirect dependency on both libavcodec53 and
 libavcodec54, not by ABI breakage.

Could you please explain what the problem is then becasue I don't see it
(I really want to learn here). As I understand it, if you get
libavdevice53 in a newer version it should still work with stuff that
was build against an older version, right? If it breaks, the soname
should be updated and the packagename changed, so that the libraries can
be co-installed. So I guess you see the problem elsewhere?

Paul





signature.asc
Description: OpenPGP digital signature

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Thu, Mar 21, 2013 at 08:04:10AM +0100, Paul Gevers wrote:
  Maybe I've picked the wrong example, the actual problem was with
  libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
  but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
  my binary ended up importing either libavcodec53 and libavcodec54 when
  both were installed and did not work.
  If this is true, and I must say I may have had the same experience,
  isn't this hinting at a bug in libavdevice53, not being stable enough to
  keep the same SONAME? I think you should file a bug against libavdevice53.
  Why? The problem is caused by indirect dependency on both libavcodec53 and
  libavcodec54, not by ABI breakage.
 Could you please explain what the problem is then becasue I don't see it
 (I really want to learn here). As I understand it, if you get
 libavdevice53 in a newer version it should still work with stuff that
 was build against an older version, right? If it breaks, the soname
 should be updated and the packagename changed, so that the libraries can
 be co-installed. So I guess you see the problem elsewhere?
If your app is linked against libavcodec53 and against libavdevice53 and
libavdevice53 is linked against libavcodec54 and libavcodec* doesn't use
symbol versioning, your app will crash because of symbol conflicts.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Paul Gevers]

Please ignore the mail below, I think I understand that part now.

libavdevice53 itself depends on libavcodec5{3|4} depending on where it
comes from.

Paul

On 21-03-13 08:04, Paul Gevers wrote:
 Hi Andrey,
 
 On 21-03-13 07:46, Andrey Rahmatullin wrote:
 On Wed, Mar 20, 2013 at 07:17:50PM +0100, Paul Gevers wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.
 If this is true, and I must say I may have had the same experience,
 isn't this hinting at a bug in libavdevice53, not being stable enough to
 keep the same SONAME? I think you should file a bug against libavdevice53.
 Why? The problem is caused by indirect dependency on both libavcodec53 and
 libavcodec54, not by ABI breakage.
 
 Could you please explain what the problem is then becasue I don't see it
 (I really want to learn here). As I understand it, if you get
 libavdevice53 in a newer version it should still work with stuff that
 was build against an older version, right? If it breaks, the soname
 should be updated and the packagename changed, so that the libraries can
 be co-installed. So I guess you see the problem elsewhere?
 
 Paul
 
 
 




signature.asc
Description: OpenPGP digital signature

Re: Build-Depends versioning and binary Depends versioning

[Russ Allbery]

Andrey Rahmatullin w...@wrar.name writes:

 If your app is linked against libavcodec53 and against libavdevice53 and
 libavdevice53 is linked against libavcodec54 and libavcodec* doesn't use
 symbol versioning, your app will crash because of symbol conflicts.

Which is why all shared libraries should use at least trivial symbol
versioning that assigns all symbols a version that changes with the
SONAME.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li9gsp60@windlord.stanford.edu

Re: Build-Depends versioning and binary Depends versioning

[Paul Wise]

On Fri, Mar 22, 2013 at 12:17 AM, Russ Allbery wrote:

 Which is why all shared libraries should use at least trivial symbol
 versioning that assigns all symbols a version that changes with the
 SONAME.

Perhaps a pedantic/info lintian complaint is in order?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FoB=jo3byas5vuqx4okktisr17ourqkgac-9reif1...@mail.gmail.com

Re: Build-Depends versioning and binary Depends versioning

[Antonio Ospite]

On Tue, 19 Mar 2013 18:51:26 +0100
Jakub Wilk jw...@debian.org wrote:

 * Antonio Ospite osp...@studenti.unina.it, 2013-03-19, 16:15:
 for a package I am working on, I am setting versioned Build-Depends, to 
 avoid using newer libav versions which would break compilation, e.g.:
 
  libavcodec-dev ( 6:9)
 
 Compilation under pbuilder for Sid goes fine, but the binary packages 
 are still allowed to be installed with newer libav binary packages:
 
   libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)
 
 A well-behaved shared library package won't break binary compatibility 
 without changing package name. In fact, the package name has changed to 
 libavcodec54. So nothing wrong with the dependency as far as I can tell.
 

Maybe I've picked the wrong example, the actual problem was with
libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
my binary ended up importing either libavcodec53 and libavcodec54 when
both were installed and did not work.

I think it will be enough to require libavdevice53 ( 6:9) in my case.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130320155413.b8798d09e5005c0425f81...@studenti.unina.it

Re: Build-Depends versioning and binary Depends versioning

[Antonio Ospite]

On Tue, 19 Mar 2013 10:10:51 -0700
Russ Allbery r...@debian.org wrote:

 Antonio Ospite osp...@studenti.unina.it writes:
 
  Should I restrict the Depends for the binary packages by hand in
  debian/control? For example adding:
 
  libavcodec53 ( 6:9)
 
  to the binary package I am interested in restricting?
 
 Yes.  The shared library dependency information otherwise comes from
 shlibs/symbols, which won't take into account restrictions on the build
 dependency.
 

Thanks Russ.

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130320155440.7f0611c46f2046d604dea...@studenti.unina.it

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Wed, Mar 20, 2013 at 03:54:13PM +0100, Antonio Ospite wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.
 
 I think it will be enough to require libavdevice53 ( 6:9) in my case.
Strictly speaking this restriction won't guarantee anything about
libavdevice53 dependencies.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Paul Gevers]

On 20-03-13 15:54, Antonio Ospite wrote:
 Maybe I've picked the wrong example, the actual problem was with
 libavdevice53, the same soname is used for either 0.8.5-1 and 9.3-1,
 but 9.3-1 links to libavcodec54 while 0.8.5-1 links to libavcodec53, so
 my binary ended up importing either libavcodec53 and libavcodec54 when
 both were installed and did not work.

If this is true, and I must say I may have had the same experience,
isn't this hinting at a bug in libavdevice53, not being stable enough to
keep the same SONAME? I think you should file a bug against libavdevice53.

Paul



signature.asc
Description: OpenPGP digital signature

Build-Depends versioning and binary Depends versioning

[Antonio Ospite]

Hi,

for a package I am working on, I am setting versioned Build-Depends, to
avoid using newer libav versions which would break compilation, e.g.:

libavcodec-dev ( 6:9)

Compilation under pbuilder for Sid goes fine, but the binary packages
are still allowed to be installed with newer libav binary packages:

 libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)

As you can see I can still install the package on a system which has
libavcodec53 9.3-1 from experimental, as the binary dependency is
just greater than, the strictly minor one from the Build-Depends didn't
propagate to the binary packages.

Thinking about it I can see why this is happening: I specified the
Build-Depends for the -dev packages, not for the corresponding
libraries, but naively I thought the build system can figure out the
relationship between the two.

Should I restrict the Depends for the binary packages by hand in
debian/control? For example adding:

libavcodec53 ( 6:9)

to the binary package I am interested in restricting?

For reference this is the debian/control file of the package:
http://git.ao2.it/libam7xxx.git/blob/6d2d8613958e1f0ef011e9d848426086caafe9db:/debian/control

The doubt is about the libam7xxx-bin package.

Tell me if you need more details or if I was not clear enough.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130319161557.4c0f48a793d44da3f581b...@studenti.unina.it

Re: Build-Depends versioning and binary Depends versioning

[Andrey Rahmatullin]

On Tue, Mar 19, 2013 at 04:15:57PM +0100, Antonio Ospite wrote:
 Compilation under pbuilder for Sid goes fine, but the binary packages
 are still allowed to be installed with newer libav binary packages:
 
libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)
Of course, because it is expected that a binary built with a given library
version will work with all newer versions of that library having the same
soname.

 As you can see I can still install the package on a system which has
 libavcodec53 9.3-1 from experimental, as the binary dependency is
 just greater than, the strictly minor one from the Build-Depends didn't
 propagate to the binary packages.
Of course it didn't, there is no such mechanisms because there is no need
for them.

 Thinking about it I can see why this is happening: I specified the
 Build-Depends for the -dev packages, not for the corresponding
 libraries, but naively I thought the build system can figure out the
 relationship between the two.
It cannot and it would be strange if it did.

 Should I restrict the Depends for the binary packages by hand in
 debian/control?
Do you have any reasons to do that? Are you sure that the package will not
work with newer versions?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Build-Depends versioning and binary Depends versioning

[Russ Allbery]

Antonio Ospite osp...@studenti.unina.it writes:

 Should I restrict the Depends for the binary packages by hand in
 debian/control? For example adding:

   libavcodec53 ( 6:9)

 to the binary package I am interested in restricting?

Yes.  The shared library dependency information otherwise comes from
shlibs/symbols, which won't take into account restrictions on the build
dependency.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9pziack@windlord.stanford.edu

Re: Build-Depends versioning and binary Depends versioning

[Jakub Wilk]

* Antonio Ospite osp...@studenti.unina.it, 2013-03-19, 16:15:
for a package I am working on, I am setting versioned Build-Depends, to 
avoid using newer libav versions which would break compilation, e.g.:


libavcodec-dev ( 6:9)

Compilation under pbuilder for Sid goes fine, but the binary packages 
are still allowed to be installed with newer libav binary packages:


 libavcodec53 (= 6:0.8.3-1~) | libavcodec-extra-53 (= 6:0.8.5)


A well-behaved shared library package won't break binary compatibility 
without changing package name. In fact, the package name has changed to 
libavcodec54. So nothing wrong with the dependency as far as I can tell.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130319175126.ga5...@jwilk.net

how to document removed Build-Depends in debian/changelog (Re: viennacl at mentors)

[Bart Martens]

On Sun, Jul 15, 2012 at 12:58:11PM +0200, Michael Wild wrote:
 On 07/14/2012 11:13 AM, Bart Martens wrote:
  Hi Michael,
  
  Are you aware of the comment at mentors ?
  http://mentors.debian.net/package/viennacl
  
  Regards,
  
  Bart Martens
  
 
 Hi Bart
 
 I just had a look at the changelog, and it mentions Remove unused
 build-deps.

I see that now too.  So actually you did mention it, and I overlooked it.

 Is that not enough?

Maybe this is enough for some sponsors.  I'm not sure.

 Do I need to list the individually?

I would mention this in debian/changelog :

  * debian/control: No longer Build-Depends: poppler-utils, asciidoc, lynx.

But I don't know how detailed such information must be for debian-policy.
Sometimes it is useful to also mention the reasons.  I'm adding debian-mentors
in cc so that other sponsors can comment if they want to.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120715112514.ga2...@master.debian.org

Re: how to document removed Build-Depends in debian/changelog (Re: viennacl at mentors)

[Charles Plessy]

Le Sun, Jul 15, 2012 at 11:25:14AM +, Bart Martens a écrit :
 
 I would mention this in debian/changelog :
 
   * debian/control: No longer Build-Depends: poppler-utils, asciidoc, lynx.
 
 But I don't know how detailed such information must be for debian-policy.
 Sometimes it is useful to also mention the reasons.  I'm adding debian-mentors
 in cc so that other sponsors can comment if they want to.

Hi all,

Policy's section 4.4 indicates that Changes in the Debian version of the
package should be briefly explained in the Debian changelog file
debian/changelog.  In that sense, the entry Remove unused build-deps is
already quite informative as it provides the explanation for the change: the
entries were not used.

For packages that I maintain in a Git repository, I tend to become brief like
this in my changelogs, and more verbose in the corresponding commits, for which
the changelog mentions the first numbers of the hash ID.  But this is a matter
of taste; all in all, it does not cost much to fill up the changelog line with
more information.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120715114924.ge32...@falafel.plessy.net

Re: how to document removed Build-Depends in debian/changelog (Re: viennacl at mentors)

[Michael Wild]

On 07/15/2012 01:49 PM, Charles Plessy wrote:
 Le Sun, Jul 15, 2012 at 11:25:14AM +, Bart Martens a écrit :

 I would mention this in debian/changelog :

   * debian/control: No longer Build-Depends: poppler-utils, asciidoc, lynx.

 But I don't know how detailed such information must be for debian-policy.
 Sometimes it is useful to also mention the reasons.  I'm adding 
 debian-mentors
 in cc so that other sponsors can comment if they want to.
 
 Hi all,
 
 Policy's section 4.4 indicates that Changes in the Debian version of the
 package should be briefly explained in the Debian changelog file
 debian/changelog.  In that sense, the entry Remove unused build-deps is
 already quite informative as it provides the explanation for the change: the
 entries were not used.
 
 For packages that I maintain in a Git repository, I tend to become brief like
 this in my changelogs, and more verbose in the corresponding commits, for 
 which
 the changelog mentions the first numbers of the hash ID.  But this is a matter
 of taste; all in all, it does not cost much to fill up the changelog line with
 more information.
 
 Have a nice day,
 

Thanks Bart and Charles for the feedback. I uploaded a new version that
now contains commit hashes for the entries of the new version and also
explains what build dependencies have been removed. Further, a few
commits with changes I considered to be covered by other entries are now
also present in the changelog.

Michael


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5002e343.3070...@gmail.com

Re: optional package in Build-Depends (how?)

[Dmitry Smirnov]

Hi Russ,

On Monday 27 February 2012 17:59:28 Russ Allbery wrote:
 
  Another package I was recently testing on GNU Hurd where some tests were
  failing (even though the package is working).
 
 A bug in the test suite?  It's worth being careful about assuming that the
 package is working when the tests are failing.  :)

Sorry, sorry, never mind. :) Actually I couldn't find peace with it so I 
checked again I realised that tests actually are not failing on Hurd. 
Fortunately I was wrong. :) All good, no need to ignore.

 
  So again I had to ignore post-build test(s) failure.
 
 I don't think that makes sense to do for Hurd, actually.  The package
 needs to be ported to it; I would let the build fail until that's
 happened.  That may mean just porting the test suite or the test suite may
 be uncovering a real issue.  That's generally what I do with any
 non-release architecture until I have time to do the (low priority,
 usually) porting work.  You don't want to accidentally hide failures that
 need porting effort by making the build succeed artificially.

Fully agreed.


  Testing still useful to me when I read build logs, but I'm very
  reluctant to introduce a potential failure point with dependency more
  strict than necessary.
 
 Making the *dependency* strict isn't going to add a failure point.  It's
 not like valgrind is going to disappear on i386 and amd64.

True, good point to keep in mind when considering.


 If the build failures are mostly due to bugs in the test suite, I agree
 with you.  That's the criteria on which I'd make the decision.  If the
 tests are finding bugs, then the failures are valuable and shouldn't be
 suppressed.
 
That's common sense, I can only agree.


  And it appears to me that if tests failure is already pretty much
  ignored is would be acceptable to make tests optional with weak build
  dependency.
 
 However, Debian quite intentionally does not have such a thing as a weak
 build dependency, nor do I think such a thing is appropriate here.
 Rather, I think you should make a decision: either depend on the tools
 required to run the tests and ignore the test failures (if you think
 they're bugs in the test suite and not the package) if the output is
 valuable, or don't depend on the tools and skip the tests.

Thank you, I think this is a good advice. I'll keep it in mind.

All the best,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202272049.33489.only...@member.fsf.org

Re: optional package in Build-Depends (how?)

[Dmitry Smirnov]

In case someone is tempted to try Build-Depends like check | dpkg,
it doesn't work at all in pbuilder which is smart enough to notice that dpkg 
is already installed so it never pulls 'check'. 

(Anyway particular example with check is silly because check is available on 
all architectures)

Apart from that such approach will provoke a nasty lintian error.

So this idea is not worth the effort. 

As Russ Albury noticed earlier, Debian quite intentionally does not have such 
a thing as a weak build dependency, nor do I think such a thing is appropriate 
here.


Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202280245.33508.only...@member.fsf.org

Re: optional package in Build-Depends (how?)

[gregor herrmann]

On Tue, 28 Feb 2012 02:45:33 +1100, Dmitry Smirnov wrote:

 In case someone is tempted to try Build-Depends like check | dpkg,
 it doesn't work at all in pbuilder which is smart enough to notice that dpkg 
 is already installed so it never pulls 'check'. 

And it also doesn't work -- the other way round -- on the buildds
where sbuild is configured to only look at the first alternative.

Cheers,
gregor 
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bob Dylan: Standing In The Doorway


signature.asc
Description: Digital signature

optional package in Build-Depends (how?)

[Dmitry Smirnov]

Dear mentors,

I have an interesting problem on my hands:

The package I need to build have optional build dependency (libgpm-dev)
which is not available on all platforms.

If I just put it to Build-Depends, package will FTBFS on some platforms.

So idea is to specify an optional (soft) build-dependency like

Build-Depends: libgpm-dev | TRUE

where 'TRUE' would stand for essential package like 'dpkg'.

However I suspect there must be a better way to do that, a practical 
equivalent to hypothetical 'Build-Recommends'.

What would be the best practice for such case?
Any suggestions?

Thank you.

All the best,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202271251.20803.only...@member.fsf.org

Re: optional package in Build-Depends (how?)

[Paul Wise]

See section 7.1 of debian-policy for examples on how to do that (you
probably want linux-any for the arch):

http://www.debian.org/doc/debian-policy/ch-relationships.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6GGCM8N3g1iWMhYzcdPWBu7GWmzK9e7BQ7w=rdzq6k...@mail.gmail.com

Re: optional package in Build-Depends (how?)

[Dmitry Smirnov]

Hi Paul,

Thanks for quick reply.

On Monday 27 February 2012 13:00:32 Paul Wise wrote:
 See section 7.1 of debian-policy for examples on how to do that (you
 probably want linux-any for the arch):
 
 http://www.debian.org/doc/debian-policy/ch-relationships.html

Indeed it probably could be written as 

Build-Depends: libgpm-dev [linux-any]

But the obvious drawback would be the requirement to know all architectures
where this package is available.
In this case Build-Depends configuration will be ineffective against changes.
Maintainer will have to track if the package was ported to new architecture 
and maintaining such relationships may potentially turn into expanded list of 
architectures.
Perhaps it will work beautifully for dependencies which will never be ported.

But let's discuss more general case: 
 what if optional dependency is not ported to target architecture yet,
 or if if is not available in backports?

There are might be situations where defining optional build dependencies 
without architecture wildcard may be more error-proof and easier to maintain.

Another case I'm thinking of is when upstream is using unit-testing framework 
like 'valgrind'. I like to have post-build tests enabled. But this 
functionality requires an optional dependency. I don't want to risk my package 
to FTBFS because I put dependency only needed for unit tests to Build-Depends 
and it is not available on all our platforms. In such case using architecture 
wildcard is just inappropriate because availability of such package (may) have 
nothing to do with architecture. 

Specifically regarding 'libgpm-dev', I've made a list of architectures where 
it is available (below). At the moment I have no idea what 's390x' is (linux 
or not) so I have doubts regarding architecture wildcars to use.
(OK, I admit I've checked with 'type-handling any linux-gnu' command but I'm 
still confused how to use architecture wildcards properly in this case)

All of this makes me think about the approach to use essential alternative to 
make sure build will never fail because of my lack of understanding which 
platform will have the required package.

What do you think?

libgpm-dev
avr32   N
hppaN
hurd-i386   N
kfreebsd-amd64  N
kfreebsd-i386   N
s390x   N
alpha   Y
amd64   Y
armel   Y
i386Y
ia64Y
m68kY
mipsY
mipsel  Y
powerpc Y
armhf   Y
powerpcspe  Y
s390Y
sh4 Y
sparc   Y
sparc64 Y



Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202271342.28308.only...@member.fsf.org

Re: optional package in Build-Depends (how?)

[Craig Small]

On Mon, Feb 27, 2012 at 01:42:28PM +1100, Dmitry Smirnov wrote:
 Indeed it probably could be written as 
 
 Build-Depends: libgpm-dev [linux-any]
 
 But the obvious drawback would be the requirement to know all architectures
 where this package is available.
 In this case Build-Depends configuration will be ineffective against changes.
That's the problem I have with mudlet.
  libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386],
  liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386],

It's not pretty and basically means if other arches come along and
support libluajit I have to manually fix it.  I don't think I could use
or | because it didn't work on some build systems.

A or nothing would be handy but I always get worried that you will
miss linking because of a transistional bump then the program
behaviour changes.

Imagine if on the armel libluajit is not available temporarily. I think
its better to fail to build than to issue out a package without that
linking.

Specifically to your testing, valgrind testing should probably be
opportunistic, so test if valgrind is available and don't otherwise. I
think dejagnu does it that way.

 - Craig

-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120227030921.gb1...@enc.com.au

Re: optional package in Build-Depends (how?)

[Dmitry Smirnov]

Hi Craig,

Thak you for sharing your experience.

On Monday 27 February 2012 14:09:21 Craig Small wrote:
 That's the problem I have with mudlet.
   libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386],
   liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386],
 

Very interesting and useful.
This is exactly what I'm afraid of. How can fellow maintainer track the 
changes in all architectures effectively? I imagine the maintenance pain for 
such configuration and it is probably breaks once in a while...

 It's not pretty and basically means if other arches come along and
 support libluajit I have to manually fix it.  I don't think I could use
 or | because it didn't work on some build systems.

I see...


 A or nothing would be handy but I always get worried that you will
 miss linking because of a transistional bump then the program
 behaviour changes.
 
 Imagine if on the armel libluajit is not available temporarily. I think
 its better to fail to build than to issue out a package without that
 linking.

This is a very valid point, thank you.
You're right, if libgpm-dev is not available on i386 or amd64 for whatever 
reason, build should fail rather than ignore the problem.
Which makes this dependency package optional only on some architectures so I 
probably need to use something like 

   libgpm-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
or 
   libgpm-dev [linux-any],

It's not too bad after all.

 
 Specifically to your testing, valgrind testing should probably be
 opportunistic, so test if valgrind is available and don't otherwise. I
 think dejagnu does it that way.

OK, so for really optional packages like 'check' or 'bison' it may be 
appropriate to use something like check | dpkg if we're not linking against 
it.

I understand it much better now.

Thank you.

Cheers,
Dmitry


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201202271518.25990.only...@member.fsf.org

Re: optional package in Build-Depends (how?)

[Russ Allbery]

Dmitry Smirnov only...@member.fsf.org writes:
 On Monday 27 February 2012 14:09:21 Craig Small wrote:

 Specifically to your testing, valgrind testing should probably be
 opportunistic, so test if valgrind is available and don't otherwise. I
 think dejagnu does it that way.

 OK, so for really optional packages like 'check' or 'bison' it may be
 appropriate to use something like check | dpkg if we're not linking
 against it.

I would only consider using a hack like this if the package really isn't
available everywhere.  For something like bison, just build-depend on
bison and be done with it.  As much as possible, you should try to ensure
that the package builds exactly the same way everywhere, using the same
tools, and only back off from that if some tool really isn't available at
all on some target architecture.

Even with valgrind, personally I'd just list a specific set of
architectures on which valgrind is required, even if you also
opportunistically test for its existence.  There's no reason to allow
*not* running valgrind tests on i386 and amd64.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gz86gsc@windlord.stanford.edu