Re: Build-Depends :native

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 archi

Build-Depends :native

-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

Re: Build-Depends for a Python wrapper

me 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: Build-Depends for a Python wrapper

g/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 (&

Build-Depends for a Python wrapper

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

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

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.

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

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], [],

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

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 con

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

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

Re: build-depends for different distro releases

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

Re: build-depends for different distro releases

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-

build-depends for different distro releases

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), lib

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

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 t

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

Ł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’

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

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

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

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 th

Cross-compiling a package that build-depends on Python

. 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

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

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 there any sensible way to know what qt5 devel packages might be needed as build-depends

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

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

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

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

l 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 provi

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

his 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)

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: >

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

ssage 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 ?

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

Re: build-depends on a _source_ package ?

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

build-depends on a _source_ package ?

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

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

+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 >> >

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

[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-

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

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.

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

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: - pyth

Re: Build-Depends vs Depends

gt; 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

Re: Build-Depends vs Depends

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 us

Re: Build-Depends vs Depends

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.

Re: Build-Depends vs Depends

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 unin

Re: Build-Depends vs Depends

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

Re: Build-Depends vs Depends

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:

Re: Build-Depends vs Depends

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

Re: Build-Depends vs Depends

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 B

Re: Build-Depends vs Depends

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 alre

Re: Build-Depends vs Depends

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

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 >

Re: Build-Depends vs Depends

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-D

Re: Build-Depends vs Depends

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

Re: Build-Depends vs Depends

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 wel

Build-Depends vs Depends

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

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

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

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

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 > >>

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

-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.

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

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

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

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

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

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

Re: Build-Depends on source itself

hat 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

Re: Build-Depends on source itself

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

Re: Build-Depends on source itself

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 >>

Build-Depends on source itself

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

Re: Build-Depends on source itself

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 >

Build-Depends on source itself

-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

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

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 ;)

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

* 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

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

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

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

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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,

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

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

Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

, 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

Re: Build-Depends versioning and binary Depends versioning

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

Re: Build-Depends versioning and binary Depends versioning

* 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

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

: 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

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

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

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

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

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

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

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

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

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

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

optional package in Build-Depends (how?)

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

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

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

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

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

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

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

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

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

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

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

  1   2   3   4   5   >