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
-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
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
>
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 (&
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
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. Th
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], [], [Descript
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 configur
gitimate, 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 anythi
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 th
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,
lib
is 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)
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
Ł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
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
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 fi
. 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
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 pack
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
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 QPushButto
o 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
ccording this it should be found with my provided Build-Depends.
Kind regards
Andreas.
--
http://fam-tille.de
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:
>
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 ,
Section: science
Priority: optional
Build-Depends: debhelper (>
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 sol
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 onl
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-
n 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:
>> &
[Sandro Tosi 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 depe
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.
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
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 bui
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, exce
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?
R
On Jan 2, 2017 4:56 PM, "Octavio Alvarez" 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.
I
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
htt
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
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
Taylor Kline 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
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
Thank you, Octavio. Does this mean apt will temporarily install the
Build-Depends
packages and remove them after the installation completes?
On 01/01/2017 04:07 PM, Ben Finney wrote:
> Taylor Kline 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
Taylor Kline 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
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 le
Taylor Kline 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, a
What is the difference? How are they treated differently during the
apt installation process? Thanks :)
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 u
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
> >>
-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.
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 m
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
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 pa
d 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
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 go
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
>> i
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-s
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
> sour
-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
sou
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 wrote:
> (btw it's not needed "a local build", `vim /usr/bin/pdebuild` is enough :P)
of course, I did so ;)
--
Regards,
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-build
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 i
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 wrote:
> > So you have to pass "-d" (for making the checks non-fatal, i.e.
> > warnings, again, as they were b
Hm, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786690
On Thu, 25 Jun 2015 15:14:33 +0200
gregor herrmann 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 --de
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
>
> 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 m
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
so
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
On Sat, Nov 15, 2014 at 6:24 PM, Cameron Norman
wrote:
> El sáb, 15 de nov 2014 a las 5:56 , Vincent Cheng
> escribió:
>
> Hi, On Sat, Nov 15, 2014 at 5:51 PM, Cameron Norman
> wrote:
>
> Can packages like libjson-java in sid migrate to jessie after the freeze in
> situations like this? Or does
El sáb, 15 de nov 2014 a las 5:56 , Vincent Cheng
escribió:
Hi,
On Sat, Nov 15, 2014 at 5:51 PM, Cameron Norman
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 quest
Hi,
On Sat, Nov 15, 2014 at 5:51 PM, Cameron Norman
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-ment
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 libjso
* Ben Finney , 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-
Ben Finney 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
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
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.or
Andrey Rahmatullin 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 l
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 +01
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 binar
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 w
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
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 libavcod
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 im
On Tue, 19 Mar 2013 10:10:51 -0700
Russ Allbery wrote:
> Antonio Ospite 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.
On Tue, 19 Mar 2013 18:51:26 +0100
Jakub Wilk wrote:
> * Antonio Ospite , 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
* Antonio Ospite , 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
Antonio Ospite 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/symb
y 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
> Bu
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
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 d
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.
&
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 mentio
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'.
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 availa
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 wh
Dmitry Smirnov writes:
> It makes perfect sense for complete (working) test suits.
> I had an experience with valgrind only recently when upstream introduced
> yet-to-be completed tests which are failing everywhere so far.
> I'm already ignoring tests failure using override
> override_dh_auto
Hi Russ,
On Monday 27 February 2012 15:28:51 Russ Allbery wrote:
> 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 o
Dmitry Smirnov 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
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 an
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 th
bly 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 w
1 - 100 of 530 matches
Mail list logo
