On Mon, Dec 19, 2016 at 02:15:14PM +0800, Paul Wise wrote:
> On Mon, Dec 19, 2016 at 1:54 PM, gustavo panizzo (gfa) wrote:
>
> > Is there any tool I can use to rebuild all packages which B-D/D on my
> > package? i want to do a local test before bumping it on the archive
>
> apt install ratt
Poor
On Mon, Dec 19, 2016 at 1:54 PM, gustavo panizzo (gfa) wrote:
> Is there any tool I can use to rebuild all packages which B-D/D on my
> package? i want to do a local test before bumping it on the archive
apt install ratt
> Extra points for running the autopkgtests (if any)
You should use autopk
Hello
Is there any tool I can use to rebuild all packages which B-D/D on my
package? i want to do a local test before bumping it on the archive
Extra points for running the autopkgtests (if any)
thanks!
PS: pkg is python-pytest-timeout
--
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
key
Hi Vincent
On 28/4/2015 23:09, Vincent Cheng wrote:
> I don't have the source package in front of me so I can't say for
> sure, but my first (and only) guess for why this would happen is if
> the package's clean target has additional dependencies (which don't
> actually need to be declared in buil
et the .deb packages.
>>
>> But if I extract the source package and start the compilation inside
>> the extracted directory with:
>> $ sudo -E pdebuild --pbuilder cowbuilder --debbuildopts -sa
>>
>> then the process aborts when it checks build-deps.
>> Here
rectory with:
> $ sudo -E pdebuild --pbuilder cowbuilder --debbuildopts -sa
>
> then the process aborts when it checks build-deps.
> Here [1] the detailed output of the above command.
>
> I'd expect to see the same behaviour with both commands, but in the
> first case
ts when it checks build-deps.
Here [1] the detailed output of the above command.
I'd expect to see the same behaviour with both commands, but in the
first case cowbuilder solves the build-deps correctly invoking
/usr/lib/pbuilder/pbuilder-satisfydepends, instead in the second case
it does not
Hi,
Quoting Daniel Lintott (2014-06-01 00:15:09)
> Okay... In fairness I haven't tried that as yet... But the option doesn't
> appear to mentioned in the manpage [0].
>
> [0]
> http://manpages.debian.org/cgi-bin/man.cgi?query=dose-builddebcheck&apropos=0&sektion=0&manpath=Debian+7.0+wheezy&forma
On 31 May 2014 23:02:49 BST, Johannes Schauer wrote:
>Hi,
>
>Quoting Daniel Lintott (2014-06-01 00:00:03)
>> I've had a look at dose-builddebcheck, but this doesn't seem to have
>an
>> option for running on a single package.
>
>dose-builddebcheck is what you are looking for and it can check a
>s
Hi,
Quoting Daniel Lintott (2014-06-01 00:00:03)
> I've had a look at dose-builddebcheck, but this doesn't seem to have an
> option for running on a single package.
dose-builddebcheck is what you are looking for and it can check a single
package by using the --checkonly option.
cheers, josch
-
Hi Mentors!
Does anybody know if there is a way of checking whether the
Build-Depends of a package would be able to be satisfied on a particular
release e.g wheezy.
For example: I take a package from testing to create a backport to
wheezy and want to know if Build-Depends can be satisfied a
t;a month ago, I had an upload sponsored for some minor cleanups.
> >Currently, it's still in the 'building' state on sparc and mips[1].
> >
> >I've taken a look at the buildd logs[2][3], and it seems that last
> >month, it failed to build on those arches du
g' state on sparc and mips[1].
I've taken a look at the buildd logs[2][3], and it seems that last
month, it failed to build on those arches due to uninstallable
build-deps. Will the buildds automatically requeue my package once the
build-deps become installable? If not, is there a conveni
seems that last
month, it failed to build on those arches due to uninstallable
build-deps. Will the buildds automatically requeue my package once the
build-deps become installable? If not, is there a convenient way to
know whether they're installable on those arches now?
Thanks,
Bryan Donlan
uch priority should
> not be added to build-deps...
If the package is not essential or build essential, you do
need to add the required build dependency.
manoj
--
I appoint you ambassador to Fantasy Island!!!
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian
On 1/29/07, Laurent Bigonville <[EMAIL PROTECTED]> wrote:
Could someone upload the new package for me?
Uploaded!
Thank you for your work.
Best regards,
Nelson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
I've added procps as a build-dep (easiest thing to do).
Could someone upload the new package for me?
http://mentors.debian.net/debian/pool/main/p/pam-keyring/pam-keyring_0.0.8-2.dsc
Regards
Laurent Bigonville
pgpmuKw9tLHaW.pgp
Description: PGP signature
ecause 'kill' is
> > > missing. /bin/kill is part of the procps package which has a
> > > required priority. I thought that packages with such priority
> > > should not be added to build-deps...
> >
> > Why does it need /bin/kill during the build pro
On Mon, 29 Jan 2007, Laurent Bigonville wrote:
> Hi,
>
> My package (pam-keyring) FTBFS on some buildd[1] because 'kill' is
> missing. /bin/kill is part of the procps package which has a required
> priority. I thought that packages with such priority should not be
>
Hi Laurent!
On 1/29/07, Laurent Bigonville <[EMAIL PROTECTED]> wrote:
Sould I add procps package to the build-deps or is this a problem
with buildd?
I am not 100% sure, but based on the explanation below, I would say
that you need to add procps as a build-dep:
cdebootstrap has 3 flavo
Hi,
My package (pam-keyring) FTBFS on some buildd[1] because 'kill' is
missing. /bin/kill is part of the procps package which has a required
priority. I thought that packages with such priority should not be
added to build-deps...
Sould I add procps package to the build-deps or is this
On Sun, Oct 20, 2002 at 12:20:29AM +0200, Robert Bihlmeyer wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > All packages have to be buildable with the current release. And this
> > does not include non-us if you happen to be in the us.
>
> Nope, you may freely download from non-us.debian.or
Sven Luther <[EMAIL PROTECTED]> writes:
> All packages have to be buildable with the current release. And this
> does not include non-us if you happen to be in the us.
Nope, you may freely download from non-us.debian.org, even if you're
currently in the USofA.
--
Robbe
signature.ng
Descriptio
On Sun, Oct 20, 2002 at 12:20:29AM +0200, Robert Bihlmeyer wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > All packages have to be buildable with the current release. And this
> > does not include non-us if you happen to be in the us.
>
> Nope, you may freely download from non-us.debian.or
Sven Luther <[EMAIL PROTECTED]> writes:
> All packages have to be buildable with the current release. And this
> does not include non-us if you happen to be in the us.
Nope, you may freely download from non-us.debian.org, even if you're
currently in the USofA.
--
Robbe
signature.ng
Descripti
rule should be interpreted for Build-deps and Suggests?
> Can a non non-US pkg Build-dep on or Suggest a non-US pkg?
>
> My guess is that the non-US limitation refers to _distribution_ of
> binaries. So a GPL package which Build-deps on a non-US one, but which
> does not Depends on it,
As I can read from policy 2.1.5:
"A package depends on another package which is distributed via the non-us
server has to be stored on the non-us server as well."
How this rule should be interpreted for Build-deps and Suggests?
Can a non non-US pkg Build-dep on or Suggest a non-US pkg?
rule should be interpreted for Build-deps and Suggests?
> Can a non non-US pkg Build-dep on or Suggest a non-US pkg?
>
> My guess is that the non-US limitation refers to _distribution_ of
> binaries. So a GPL package which Build-deps on a non-US one, but which
> does not Depends on it,
As I can read from policy 2.1.5:
"A package depends on another package which is distributed via the non-us
server has to be stored on the non-us server as well."
How this rule should be interpreted for Build-deps and Suggests?
Can a non non-US pkg Build-dep on or Suggest a non-US pkg?
> I was wondering if Build Deps in a source package follow dependencies.
> For example, if I build a package that requires libgnome-dev to
> compile, do I need to specify the myriad of other packages that are
> automatically installed when I install libgnome-dev?
This came up a fe
Hello,
I was wondering if Build Deps in a source package follow dependencies.
For example, if I build a package that requires libgnome-dev to
compile, do I need to specify the myriad of other packages that are
automatically installed when I install libgnome-dev?
Also, if something depends on
> I was wondering if Build Deps in a source package follow dependencies.
> For example, if I build a package that requires libgnome-dev to
> compile, do I need to specify the myriad of other packages that are
> automatically installed when I install libgnome-dev?
This came up a fe
Hello,
I was wondering if Build Deps in a source package follow dependencies.
For example, if I build a package that requires libgnome-dev to
compile, do I need to specify the myriad of other packages that are
automatically installed when I install libgnome-dev?
Also, if something depends on
33 matches
Mail list logo
