Hi,
I know that
apt-cache rdepends packageX
show me the list of the packages that depends of packageX. But, how can
I obtain the list of packages that build-depends of packageX?
Leopold
--
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Bec
was between
releases 3.340-3 and 3.370-1.
How do I specify this build dependency?
I tried:
Build-Depends: libcfitsio-dev (>= 3.310)
| libcfitsio3-dev (>= 3.310) & libcfitsio3-dev (<< 3.370-1)
and
Build-Depends: libcfitsio-dev (>= 3.310)
On Mon, 29 Oct 2018 00:25:35 +0100, Leopold Palomo-Avellaneda wrote:
> I know that
> apt-cache rdepends packageX
> show me the list of the packages that depends of packageX. But, how can
> I obtain the list of packages that build-depends of packageX?
reverse-depends -b packageX
(reverse-depends
On Mon, Oct 29, 2018 at 01:09:54AM +0100, gregor herrmann wrote:
> On Mon, 29 Oct 2018 00:25:35 +0100, Leopold Palomo-Avellaneda wrote:
>
> > I know that
> > apt-cache rdepends packageX
> > show me the list of the packages that depends of packageX. But, how can
> > I obtain the list of packages th
On Tue, 30 Oct 2018 23:52:11 +0100, Adam Borowski wrote:
> > reverse-depends -b packageX
> > (reverse-depends is in ubuntu-dev-tools)
> build-rdeps packageX
> (needs just regular devscripts, although you want dose-extra to handle B-Dep
> on Dep chains)
Interesting, I admit that I didn't know (or
Hi
El 31/10/18 a les 1:52, gregor herrmann ha escrit:
> On Tue, 30 Oct 2018 23:52:11 +0100, Adam Borowski wrote:
>
>>> reverse-depends -b packageX
>>> (reverse-depends is in ubuntu-dev-tools)
>> build-rdeps packageX
>> (needs just regular devscripts, although you want dose-extra to handle B-Dep
>
The valid way to specify "libcfitsio-dev (>= 3.310) or libcfitsio3-dev
(>= 3.310, << 3.370)" would be to use A|(B&C) = (A|B)&(A|C):
libcfitsio-dev (>= 3.310) | libcfitsio3-dev (>= 3.310), libcfitsio-dev
(>= 3.310) | libcfitsio3-dev (<< 3.370)
but you probably don't actually need that: as libc
Hi,
How to determine build dependencies?
I was using 'dpkg-depcheck -d ./configure ...', but that seems to have
included much more than necessary.
For example for emacs, using motif instead of gtk3, I get [1], but I
don't think x11proto-randr-dev, libxinerama-dev, libxrandr-dev, libgl1-
mes
T o n g writes:
> How to determine build dependencies?
Well, the best way is to read upstream documentation and possibly the
configure script and figure out what the dependencies are stated to be.
But if you're looking for more of an automatically-determined method, I
have been known to start w
Dear mentors,
in debian-astro, we have a problem with a circular dependency on two
packages that are currently prepared [1], [2]:
- the "casacore" needs the "casacore-data" package for unit tests
- the "casacore-data" needs "casacore" to be build from the source data.
The source data of casacor
Hi!
2014-09-13 20:01 GMT+07:00 Ole Streicher :
> Dear mentors,
>
> in debian-astro, we have a problem with a circular dependency on two
> packages that are currently prepared [1], [2]:
>
> - the "casacore" needs the "casacore-data" package for unit tests
>
> - the "casacore-data" needs "casacore"
On Sep 13, 2014 3:01 PM, "Ole Streicher" wrote:
>
> Dear mentors,
>
> in debian-astro, we have a problem with a circular dependency on two
> packages that are currently prepared [1], [2]:
>
> - the "casacore" needs the "casacore-data" package for unit tests
>
> - the "casacore-data" needs "casacor
the source data.
>
> What's about upload casacore with the tests disabled, then upload
> casacore-data, then re-upload casacore with the tests re-enabled?
Still, the packages would have a circular build dependency, which I think
should be avoided, right?
Best
Ole
--
To UNSUBSCRIBE,
sacore-data" needs "casacore" to be build from the source data.
> >
> > What's about upload casacore with the tests disabled, then upload
> > casacore-data, then re-upload casacore with the tests re-enabled?
>
> Still, the packages would have a ci
On Sep 13, 2014 3:20 PM, "Ole Streicher" wrote:
> Still, the packages would have a circular build dependency, which I think
should be avoided, right?
>
Well, compilers often build-depend on them own, which is even worse.
If a circular dependency could be avoided, better, but I
On 13/09/14 15:01, Ole Streicher wrote:
> Dear mentors,
>
> in debian-astro, we have a problem with a circular dependency on two
> packages that are currently prepared [1], [2]:
>
> - the "casacore" needs the "casacore-data" package for unit tests
>
> - the "casacore-data" needs "casacore" to be
Hi Alexander,
Alexander Wolf writes:
> Hi!
>
> A separate "casacore-data" on two packages - "casacore-data" &
> "casacore-tests"?
I don't see it feasible to separate. all the present contents of
casacore-data are needed for the test.
Cheers,
Benda
--
To UNSUBSCRIBE, email to debian-mentors-
Hi Gijs and Tomasz,
Gijs Molenaar writes:
> i don't think that would work, the releases of casacore-data and
> casacore are not in sync.
>
> 2014-09-13 18:31 GMT+02:00 Tomasz Buchert :
>
> Hi guys,
> if I get this right, this is only build-time dependency, right?
> What about "mergin
Alexander Wolf writes:
> A separate "casacore-data" on two packages - "casacore-data" &
> "casacore-tests"?
Sorry Alexander, I misunderstood your point at the first sight.
As later Johannes Schauer put more precisely,
> 1. split the source package as Alexander Wolf suggested so that the
> unit
.
Better to just use the bootstrapping scenario and leave the circular
build-dependency.
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
Hello,
I'm the maintainer of v4l-utils and ran into the following problem:
The last v4l-utils Debian package added a build dependency to libjpeg,
and because I also build 32bit libs on amd64 (for Skype) I had to add an
build dependency on ia32-libs-dev (where libjpeg.so lives on Debian).
B
Dear Debian Mentors,
This is with reference to a package of mine, libitpp, whose latest
version I have packaged and it is available at:
http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_4.0.1-2.dsc
What I want to know is, earlier builds never pulled in atlas3-base-dev
for the build, a
Hi list,
I received #456871. This happens since tdb-dev was upgraded from
'1.1.0-1+b1' to '1.1.1~svn26294-1', because 'usr/include/tdb.h' uses
'sig_atomic_t' without including .
I could work around that problem quite simply. However, I think it
would be preferable, if 'tdb.h' would be fixed.
My
On Mon, Jun 13, 2011 at 5:58 AM, Gregor Jasny wrote:
> Hello,
>
> I'm the maintainer of v4l-utils and ran into the following problem:
>
> The last v4l-utils Debian package added a build dependency to libjpeg,
> and because I also build 32bit libs on amd64 (for Skype)
Gregor Jasny writes:
> Hello,
>
> I'm the maintainer of v4l-utils and ran into the following problem:
>
> The last v4l-utils Debian package added a build dependency to libjpeg,
> and because I also build 32bit libs on amd64 (for Skype) I had to add an
> build dependen
(Annotation at the end)
On Thu, Dec 20, 2007 at 10:30:14AM +0530, Kumar Appaiah wrote:
> Dear Debian Mentors,
>
> This is with reference to a package of mine, libitpp, whose latest
> version I have packaged and it is available at:
>
> http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_
Hello,
On Thu, 20 Dec 2007, Kumar Appaiah wrote:
> Also, when I try to build the package on my machine outside a
> pbuilder, with the B-Deps installed, it works fine without atlas, and
> generates packages which don't depend explicitly on libatlas. However,
> the moment I try to use pbuilder on it
On 07/12/20 10:30 +0530, Kumar Appaiah said ...
> What I want to know is, earlier builds never pulled in atlas3-base-dev
> for the build, as you may see here:
>
> http://buildd.debian.org/fetch.cgi?pkg=libitpp&arch=i386&ver=4.0.0-3&stamp=1193598381&file=log&as=raw
This could just mean that atlas3
Hi!
On Thu, Dec 20, 2007 at 10:56:46AM +0530, Kapil Hari Paranjape wrote:
> The building of a package should not produce a different package if
> some additional packages not listed in "Build-Conflicts" are
> installed.
>
> In other words, if you specifically do not want "atlas3-base-dev" to
> be
On Thu, Dec 20, 2007 at 11:49:53AM +0530, Kumar Appaiah wrote:
> See this old log. The apt-get command follows the same order as
> specified in the package's Build-Depends:
> http://buildd.debian.org/fetch.cgi?&pkg=octave2.9&ver=1%3A2.9.17-1&arch=sparc&stamp=1195174810&file=log
>
> But here, it is
On 07/12/20 12:04 +0530, Kumar Appaiah said ...
> On Thu, Dec 20, 2007 at 11:49:53AM +0530, Kumar Appaiah wrote:
> > Notice that refblas3-dev is _before_ lapack3-dev. Now, if apt-get is
> > called faithfully in this order, atlas does not come in. But if it is
> > reordered, the lapack3-dev dependen
On Thu, Dec 20, 2007 at 12:01:24PM +0530, Y Giridhar Appaji Nag wrote:
> IMO, this isn't a bug. The order in which packages are listed in the
> build-depends shouldn't matter. Build-Depends: lapack3-dev | refblas3-dev
> or Build-Depends: refblas3-dev | lapack3-dev (if you please) is what you
> wa
On Thu, Dec 20, 2007 at 12:23:49PM +0530, Kumar Appaiah wrote:
> Well, I've filed one already with a patch and severity serious! It
> does affect common behaviour from earlier though. Let me downgrade it
> if it comes to that, or the maintainer objects.
OK, the verdict from #457151 is that orderin
Hello,
On Thu, 20 Dec 2007, Kumar Appaiah wrote:
> > In other words, if you specifically do not want "atlas3-base-dev" to
> > be present during the build then you should put it in
> > "Build-Conflicts".
>
> I am aware, but want to avoid it.
It may not be avoidable. See
http://lists.debia
On 10/01/2008, Frank Terbeck wrote:
> I could work around that problem quite simply. However, I think it
> would be preferable, if 'tdb.h' would be fixed.
Sure.
> My question is, if it would be the right thing to do is to reassign
> the bug to tdb-dev and add a comment about signal.h to it? Or sh
(>= fixed-version) and
state so when closing that bug. If your package gets uploaded after your
build dependency, it'll be put in Dep-Wait rather than failing. A
Dep-Wait would be something like: “Dep-Wait: $package >= $version” and
would be displayed on:
http://buildd.debian.org/~jeroen/
Cyril Brulebois <[EMAIL PROTECTED]>:
> On 10/01/2008, Frank Terbeck wrote:
[...]
> > My question is, if it would be the right thing to do is to reassign
> > the bug to tdb-dev and add a comment about signal.h to it? Or should I
> > rather create a new bug against tdb-dev about the problem?
>
> Sim
tate so when closing that bug. If your package gets uploaded after your
> build dependency, it'll be put in Dep-Wait rather than failing. A
> Dep-Wait would be something like: ???Dep-Wait: $package >= $version??? and
> would be displayed on:
> http://buildd.debian.org/~jeroen/statu
[ CC mentors list ]
Dear Joseph,
I find this change affects many packages, so I CC mentors.
On Fri, Jan 6, 2017 at 1:17 PM, Joseph Herlant wrote:
> Package: shadowsocks-libev
> Severity: wishlist
>
> Dear Maintainer,
>
> Asciidoc has been split in different packages in #637006 and #729242.
> Th
Hi,
Could somebody please explain me the meaning of the "Checking
build-dependency (indep) on amd64" migration excuse as seen on
https://qa.debian.org/excuses.php?package=pacemaker?
I think I understand the rest, although I don't know whether the
autopkgtest regression b
Hi,
>I'm thinking how to make the Build-Depends fits both sid/stretch and
>jessie-backports.
>Whether the following is good enough? or appending the version is better?
>
>Build-Depends: asciidoc-base | asciidoc
backporting asciidoc should be the right solution here
(or reverting the change for
Hi,
Another solution would be to do another change to the way the package
is split before the final release and make asciidoc be a metapackage
for asciidoc-base and not asciidoc-dblatex as proposed in #850301.
The caveat to that is that end users that were installing previous
versions of asciidoc
On Tue, Jan 15, 2019 at 7:06 PM wrote:
> Could somebody please explain me the meaning of the "Checking
> build-dependency (indep) on amd64" migration excuse as seen on
> https://qa.debian.org/excuses.php?package=pacemaker?
Looking at the code, I think it means that the mi
Paul Wise writes:
> On Tue, Jan 15, 2019 at 7:06 PM wrote:
>
>> Could somebody please explain me the meaning of the "Checking
>> build-dependency (indep) on amd64" migration excuse as seen on
>> https://qa.debian.org/excuses.php?package=pacemaker?
>
> Lo
On Wed, Jan 16, 2019 at 12:07 AM Ferenc Wágner wrote:
> Thanks, Paul, it makes sense indeed and I agree it's reasonable to do,
> but how/why is this an excuse? Is there any problem with that?
No idea, you would have to ask the release team about this.
> That gives 404 to me.
https://salsa.debi
Hi Feri,
Please CC me on reply.
>> I think I understand the rest, although I don't know whether the
>> autopkgtest regression blocks migration indefinitely. That would be
>> unfortunate, because unstable pcs needs unstable pacemaker, so they
>> deadlock...
>
> I think you will need to ask the re
While we're at it, you should also consider adding the appropriate
texlive packages to your B-D as an alternative to the tetex packages.
Sooner or later (may well happen for lenny), the tetex packages will be
removed, so you'll have to do that anyway.
--
Florent
--
To UNSUBSCRIBE, email to [EM
Hi Lucas,
could you please be more verbose why this is a RC bug? Crac was never
Build on i386 (neither was it on any other arch than amd64) exactly
because this not installable Build-Dependency. As far as I know there
is no point in restricting the Build-Architectures explicitly since once
the
On 19/04/17 at 11:28 +0200, Andreas Tille wrote:
> Hi Lucas,
>
> could you please be more verbose why this is a RC bug? Crac was never
> Build on i386 (neither was it on any other arch than amd64) exactly
> because this not installable Build-Dependency. As far as I know there
&
49 matches
Mail list logo
