On Tue Aug 20, 2024 at 12:17 AM BST, Lisandro Damián Nicanor Pérez Meyer wrote:
> But users would love to have something like 'qt6-full-dev'. And the
> reason we never provided them with this meta-package is that package
> maintainers would use it almost everywhere, dragging the whole Qt
> installa
a concept that has already existed in Debian for some
> time. There have always been metapackages or other similar cases that are
> only intended for end users and would make no sense as build dependencies,
> such as all of the task-* packages.
>
> Lintian feels like the right place t
On Mon, 19 Aug 2024 at 20:21, Samuel Thibault wrote:
>
> Hello,
>
> Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a
> ecrit:
> > But users would love to have something like 'qt6-full-dev'. And the
> > reason we never provided them with this meta-package is that package
en adding a special section in our
> policy.
I could have sworn that we already had tags like that in Lintian.
Certainly, this is a concept that has already existed in Debian for some
time. There have always been metapackages or other similar cases that are
only intended for end users and would make no
Hello,
Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a
ecrit:
> But users would love to have something like 'qt6-full-dev'. And the
> reason we never provided them with this meta-package is that package
> maintainers would use it almost everywhere, dragging the whole Q
, this approach lets package
maintainers install only the necessary build dependencies when
building their packages.
But users would love to have something like 'qt6-full-dev'. And the
reason we never provided them with this meta-package is that package
maintainers would use it almost every
On 9/26/23 10:24, Johannes Schauer Marin Rodrigues wrote:
piuparts is run outside the build chroot, not inside of it.
Thanks, that's useful info.
My best guess is that the issue here is that piuparts is installed in /sbin
and /sbin isn't in the default sudo path, but that would imply that there
Hi,
Quoting Jonathan Kamens (2023-09-26 15:20:49)
> I'm trying to use sbuild to build my package, and it's failing to find
> piuparts:
>
> | Post Build
> |
> +--
I'm trying to use sbuild to build my package, and it's failing to find
piuparts:
| Post Build |
+--+
piuparts
sudo: piuparts: command not foun
Hi Paul,
> FTBFS) but it avoids busywork for maintainers that are not involved in
> bootstrapping java. Machine time is cheap, volunteer time is not.
this is not for bootstrapping. This is to prevent building of language
bindings for e.g. Java on platforms where there is simply no Java.
This is a
mhf i386 ia64 m68k mips64el mipsel
>> powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32]
>>
>> It's also ok to use something like
>>
>> default-jdk [!hppa !hurd-i386 !kfreebsd-any]
>>
>> to be able to build with the nojava profile. I also see t
rc64 x32]
>
> It's also ok to use something like
>
> default-jdk [!hppa !hurd-i386 !kfreebsd-any]
>
> to be able to build with the nojava profile. I also see this used in many
> mono
> related build dependencies.
>
> Having such build dependencies in a
Please see https://bugs.debian.org/982085
I think it's wrong to encode build dependencies for language stacks that are not
available on some platforms, just using a profile.
Seen in gettext:
default-jdk , maven-repo-helper
and also in db5.3.
A more cooperative usage of such
uess this is a common problem which sometimes happens
>> with some packages.
>> Is there a way to rebuild all ${package} reverse build-dependencies in
>> one go in a more-or-less clean environment (chroot/container/vm)?
>
> "ratt" is supposed to do this.
>
>
ckages.
> Is there a way to rebuild all ${package} reverse build-dependencies in
> one go in a more-or-less clean environment (chroot/container/vm)?
"ratt" is supposed to do this.
I haven't personally used it yet -- if you prefer dirty hacks instead, my
way consists of the f
On Thu, Feb 09, 2017 at 03:24:48PM +0200, Eugene Zhukov wrote:
> Is there a way to rebuild all ${package} reverse build-dependencies in
> one go in a more-or-less clean environment (chroot/container/vm)?
tracker.debian.org/ratt - rebuild all the things!
--
cheers,
Hello,
I have a package (saxonhe) whose newer versions are not backwards
compatible and break other packages (build)depending on it e.g.
epubcheck. I guess this is a common problem which sometimes happens
with some packages.
Is there a way to rebuild all ${package} reverse build-dependencies in
to manually or
> automatically verify that we can do this.
>
> I expect we would need Build-Depends-Extra and debian/rules distclean to make
> that happen. Thoughts?
I guess instead of a new field you could use build profiles to mark some build
dependencies as only being needed for runn
Hi,
Quoting Scott Kitterman (2014-07-28 14:54:29)
> It is quite common for people to fix things based on the initial discussion
> about an impending MBF, so I think it would be less than impolite to not
> acknowledge that by filing bugs on obsolete data.
>
> The two packages that I show up for ar
; that time. The only thing that could change this would be if I found easily
> accessible compute time elsewhere (I asked at debian-qa@l.d.o:
> http://lists.debian.org/20140726090503.4150.56356@hoothoot )
It seems like there might be solution coming up in this thread -
good!
> I thought that
ause I'm moving places twice
> > within the next month and thus do not have a stable always-on machine
> > available during that time. The only thing that could change this would be
> > if I found easily accessible compute time elsewhere (I asked at
> > debian-qa@l.d.o
time. The only thing that could change this would be
> if I found easily accessible compute time elsewhere (I asked at
> debian-qa@l.d.o:
> http://lists.debian.org/20140726090503.4150.56356@hoothoot )
>
> I thought that hardly any build dependencies get removed over time so t
Hi,
I cannot believe I attached the wrong list once again. My sincere apologies to
fill up your inboxes like that :(
Attached are the right files and dd-list
Quoting Johannes Schauer (2014-07-28 11:34:24)
> bison, ca-certificates, default-jdk, doxygen-latex, g++-4.8-multilib,
> gcc-multilib, gcj
sts.debian.org/20140726090503.4150.56356@hoothoot )
I thought that hardly any build dependencies get removed over time so that it
would still be appropriate to fill bugreports for the June results now.
If that would not be appreciated then I'll re-run the whole thing once I
settled in at our new
On Mon, 28 Jul 2014 11:34:24 +0200, Johannes Schauer wrote:
> I attached the updated list of droppable build dependencies and build
> dependencies that can be moved to Build-Depends-Indep together with dd-list
> output.
> ==> libxml-parser-perl_2.41-1.arch-all.unusedbd <==
&g
Hi,
Quoting Johannes Schauer (2014-07-07 13:51:00)
> we would like to propose an MBF with severity wishlist to drop unused build
> dependencies in a number of source packages
I fixed many of the previous false positives of build dependencies on meta
packages (not the file contents of the p
minimal change to dpkg, apt and python-apt
into wheezy backports to solve this problem:
http://lists.debian.org/20140706211617.14505.38487@hoothoot
> - it makes the packaging more complex to understand
While this is true in one sense, one could also argue that annotating build
dependencies
Hi,
Quoting Jakub Wilk (2014-07-10 12:45:36)
> * Johannes Schauer , 2014-07-09, 16:50:
> >should build dependencies which the source package only requires after
> >setting some DEB_BUILD_OPTIONS go into Build-Depends?
>
> Probably not, unless it's one of the optione
exinfo=5.2.0.dfsg.1-3
No, building with DEB_BUILD_OPTIONS=codecoverage enables at least some
of them,
should build dependencies which the source package only requires after
setting some DEB_BUILD_OPTIONS go into Build-Depends?
Probably not, unless it's one of the optioned blessed by Po
hutils=0.3.3-1
> procps=1:3.3.9-5
> sharutils=1:4.14-2
> tcl=8.6.0+8
> texinfo=5.2.0.dfsg.1-3
>
> No, building with DEB_BUILD_OPTIONS=codecoverage enables at least some of
> them,
should build dependencies which the source package only requires after setting
some DEB_BUILD_OPTION
op 07-07-14 14:20, Johannes Schauer schreef:
> Hi,
>
> sorry I attached two wrong files containing the many false positives already
> noticed by some of the replies. Here the actual results.
>
> Sorry.
>
> cheers, josch
==> llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real <==
automake=1:1.14.1-3
Hi,
Quoting Kurt Roeckx (2014-07-09 00:36:37)
> On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
> > Kurt Roeckx
> >libtool
>
> ==> libtool_2.4.2-1.7.arch-all.unusedbd <==
> gfortran=4:4.8.2-4
>
> gfortran Depends on gfortran-4.8, and that is being used.
indeed this is the
> still useful to be later marked with once build profiles
> > > are allowed in the archive because they are obviously droppable.
> > No, marking build-dependencies with build profiles should be driven by what
> > is needed to break build-dep loops, not by what build-de
On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
> Kurt Roeckx
>libtool
==> libtool_2.4.2-1.7.arch-all.unusedbd <==
gfortran=4:4.8.2-4
gfortran Depends on gfortran-4.8, and that is being used.
>openssl (U)
==> openssl_1.0.1g-4.arch-all.unusedbd <==
m4=1.4.17-4
>From th
On Tue, Jul 08, 2014 at 09:43:02AM +0200, Johannes Schauer wrote:
> Do you think I should fill bugs for all non-empty packages that were
> already found? Or do you think there is another high chance of false
> positives for that kind of packages too?
The only other likely sources of false positiv
were resilient against breakage in
> their build-dependencies, instead of misbuilding with features disabled or
> with wrong fallback code. But this isn't easy to do in all build systems,
> and anyway this isn't something we routinely audit about our packages; we
> shouldn't r
wed in the archive because they are obviously droppable.
>
> No, marking build-dependencies with build profiles should be driven by what
> is needed to break build-dep loops, not by what build-deps are "droppable"
> without further modification of the packages. Excessive stag
Hi Johannes,
On Montag, 7. Juli 2014, Johannes Schauer wrote:
> About "systematically staying on top of those issues" I do not know how to
> proceed. I guess for that we would first need to know how many source
> packages depend on meta packages which are not completely empty (besides
> /usr/share
ositives" that were generated this way are still
> > useful to be later marked with once build profiles are
> > allowed in the archive because they are obviously droppable.
>
> No, marking build-dependencies with build profiles should be driven by what
> is needed to break
ependency is not used.
> you are correct. I expanded more on this in my other reply to Don Armstrong.
> > It would of course be better if packages were resilient against breakage in
> > their build-dependencies, instead of misbuilding with features disabled or
> > with wrong
On Mon, Jul 07, 2014 at 09:46:47PM +0200, Julien Cristau wrote:
> On Mon, Jul 7, 2014 at 11:22:42 -0700, Steve Langasek wrote:
> > For the case of pam, I would be interested in seeing the full build log
> > to understand how in the world this built successfully without libdb.
> > That's definite
On Mon, Jul 7, 2014 at 11:22:42 -0700, Steve Langasek wrote:
> For the case of pam, I would be interested in seeing the full build log to
> understand how in the world this built successfully without libdb. That's
> definitely a packaging error on my part, because without libdb,
> pam_userdb.so
ly to Don Armstrong.
> It would of course be better if packages were resilient against breakage in
> their build-dependencies, instead of misbuilding with features disabled or
> with wrong fallback code. But this isn't easy to do in all build systems,
> and anyway this isn'
Hi,
Quoting Don Armstrong (2014-07-07 20:33:37)
> On Mon, 07 Jul 2014, Johannes Schauer wrote:
> > Empty packages are not "detected". The first phase will find empty
> > packages because they do not contain any files and thus they are
> > detected as build dependenc
On Mon, 07 Jul 2014, Johannes Schauer wrote:
> Empty packages are not "detected". The first phase will find empty
> packages because they do not contain any files and thus they are
> detected as build dependencies of which no files were used. Since
> empty packages are mostl
uot;. The first phase will find empty
> packages because they do not contain any files and thus they are detected
> as build dependencies of which no files were used. Since empty packages
> are mostly meta packages and we do not want to include them, we replace
> them by a fake equivs packag
> pull in version-specific -dev packages. So something seems to be wrong with
> the detection of "empty" packages yet?
Empty packages are not "detected". The first phase will find empty packages
because they do not contain any files and thus they are detected as build
Hi Johannes,
On Mon, Jul 07, 2014 at 02:37:02PM +0200, Johannes Schauer wrote:
> Steve Langasek
>freetds
>openldap (U)
>pam
>unixodbc
There seem to still be some false positives here. pam is on the list
because of a build-dependency on libdb-dev, freetds and unixodbc are there
b
On Mon, Jul 7, 2014 at 4:51 AM, Johannes Schauer wrote:
> ==> openldap_2.4.39-1.arch-all.unusedbd <==
> debconf-utils=1.5.53
I think that's valid. According to debian/changelog, that B-D was
added long ago for debconf-mergetemplate, but if I'm reading correctly
it seems to be unused since switchi
Le lundi 07 juillet 2014 à 15:32 +0200, Johannes Schauer a écrit :
> Hi,
>
> Quoting Jérémy Lal (2014-07-07 14:12:19)
> > Consider also the case when arch:all package require a build dependency on a
> > package that only builds on some archs, to prevent the arch:all package
> > being
> > availabl
Hi,
Quoting Jérémy Lal (2014-07-07 14:12:19)
> Consider also the case when arch:all package require a build dependency on a
> package that only builds on some archs, to prevent the arch:all package being
> available on archs where its dependencies are not. nodejs and node-*
> packages are such an
On Mon, Jul 7, 2014 at 2:23 PM, Johannes Schauer wrote:
> Hi,
>
> Quoting Julian Taylor (2014-07-07 14:14:20)
>
>> If so that might explain why your pass2 did not remove these, but so far I
>> know we have no way to declare this state in our control, we only have
>> Build-Depends and Build-Depend
and the updated dd-list
Sorry for not having attached the right files in my initial email :(
cheres, josch
"Adam C. Powell, IV"
mpi-defaults (U)
Adam Conrad
eglibc (U)
freetds (U)
Alan Woodland
blcr
Alessandro Ghedini
curl
valgrind
Alessio Treglia
gpac (U)
Alexander
rst place, but
> something is broken in the build and it is being left unused.
you are correct, this should be mentioned. Here the updated text:
--%<---
Dear Maintainer,
the build dependencies $foo, $bar and $baz of this source
Hi,
Quoting Julian Taylor (2014-07-07 14:14:20)
> There seem to be a bunch of false positives for virtual/metapackages:
>
> ==> python-numpy_1.8.1-1.arch-all.unusedbd <==
> gfortran=4:4.8.2-4
> python-all-dbg=2.7.6-2
> python-all-dev=2.7.6-2
> python3-all-dbg=3.4.1~rc1-1
> python3-all-dev=3.4.1~r
Hi,
sorry I attached two wrong files containing the many false positives already
noticed by some of the replies. Here the actual results.
Sorry.
cheers, josch
==> apache2_2.4.9-1.arch-all.unusedbd.real <==
libcap-dev:amd64=1:2.22-1.2
==> apparmor_2.8.0-5.arch-all.unusedbd.real <==
dejagnu=1.5-3
:
> Hi,
>
> we would like to propose an MBF with severity wishlist to drop unused
> build
> dependencies in a number of source packages indicated by the attached two
> text
> files and the dd-list output.
>
> TLDR; We searched a selection of source packages relevant to
On Mon, Jul 7, 2014 at 1:51 PM, Johannes Schauer wrote:
>
> Can you spot obvious mistakes in the results or in the procedure used to
> generate them?
>
There seem to be a bunch of false positives for virtual/metapackages:
==> python-numpy_1.8.1-1.arch-all.unusedbd <==
gfortran=4:4.8.2-4
python-
Le lundi 07 juillet 2014 à 09:07 -0300, Henrique de Moraes Holschuh a
écrit :
> On Mon, 07 Jul 2014, Johannes Schauer wrote:
> > MBF template email:
> >
> > --%<---
> > Subject: Please consider r
On Mon, 07 Jul 2014, Johannes Schauer wrote:
> MBF template email:
>
> --%<---
> Subject: Please consider removing the build dependencies on $foo, $bar and
> $baz
> Severity: wishlist
> Usertag:
Hi,
we would like to propose an MBF with severity wishlist to drop unused build
dependencies in a number of source packages indicated by the attached two text
files and the dd-list output.
TLDR; We searched a selection of source packages relevant to bootstrapping for
build dependencies which are
xample), or something else.
As I understand it (and what I'd like) is just the possibility of specifying
source packages rather than binary packages as build-dependencies. So for
instance in my gcc-mingw-w64 package's control file, instead of specifying
Build-Depends: ..., gcc-4.6-
On Tue, 2013-05-14 at 08:50:39 +0800, Paul Wise wrote:
> On Mon, May 13, 2013 at 11:17 PM, Stéphane Glondu wrote:
> > Le 13/05/2013 15:51, Paul Wise a écrit :
> >> [...] as long
> >> as there is a way to build-depend on the build-dependencies for a
> >> sourc
On 12-05-13 04:03, Paul Wise wrote:
> On Sun, May 12, 2013 at 1:03 AM, Wookey wrote:
>
>> I'd vote for that too, as it would be very helpful for
>> cross-toolchain building. I hadn't realised that source build-deps
>> was a possibility. Is it? Does anyone have a proposal for how it might
>> work?
On Sat, May 11, 2013 at 06:03:30PM +0100, Wookey wrote:
> +++ Stephen Kitt [2013-05-09 10:46 +0200]:
> > On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey wrote:
>
> > > * source build dependencies (such that e.g binutils-mingw-w64 build
> > > depends on src:binut
On Mon, May 13, 2013 at 11:17 PM, Stéphane Glondu wrote:
> Le 13/05/2013 15:51, Paul Wise a écrit :
>> [...] as long
>> as there is a way to build-depend on the build-dependencies for a
>> source package, that should be fine. As a bonus we can get rid of
>> mk-build-deps
Le 13/05/2013 15:51, Paul Wise a écrit :
> [...] as long
> as there is a way to build-depend on the build-dependencies for a
> source package, that should be fine. As a bonus we can get rid of
> mk-build-deps :)
How so?
--
Stéphane
--
To UNSUBSCRIBE, email to debia
On Sun, May 12, 2013 at 1:15 PM, Johannes Schauer wrote:
> Should a dependency of a source package src:A on src:foo not mean that src:A
> also automatically build depends on the build dependencies of src:foo?
Not necessarily, src:A could be building with a different set of build
option
a source package src:A on src:foo not mean that src:A
also automatically build depends on the build dependencies of src:foo?
It would be weird if the transitive dependencies are taken into account for
build dependencies on binary packages but not for build dependencies on source
packages.
chee
On Sun, May 12, 2013 at 1:03 AM, Wookey wrote:
> I'd vote for that too, as it would be very helpful for
> cross-toolchain building. I hadn't realised that source build-deps
> was a possibility. Is it? Does anyone have a proposal for how it might
> work?
It isn't a possibility yet, it could be if
+++ Stephen Kitt [2013-05-09 10:46 +0200]:
> On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey wrote:
> > * source build dependencies (such that e.g binutils-mingw-w64 build
> > depends on src:binutils instead of binutils-source)
>
> Yes! That was on my list as well ;-). T
ly to do the equivalent of that proposal, but by hand
> (dpkg-buildpackage -d, and maybe temporary source changes that are never
> uploaded).
>
> dbus and dbus-glib also have cyclic build-dependencies: you can break
> the cycle by ignoring the dbus-glib dependency (which means most of the
>>> > I don't see this as a viable solution, especially if in the future the
>>> > epoch is raised bringing again conflicts between the old libav libraries
>>> > and the new one.
>>> >
>>> > --
>>> > Pino Toscano
>>>
ront-end.
I believe the current state-of-the-art for bootstrapping new
architectures, or getting a particularly "slow" architecture caught up,
is essentially to do the equivalent of that proposal, but by hand
(dpkg-buildpackage -d, and maybe temporary source changes that are never
uploaded
> libav -> x264 -> libav
AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
library. So theortically (!) this issue could be solved by two separate
source packages for the x264 frontend and the library.
- Fabian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.de
On May 4, 2012 4:43 PM, "Fabian Greffrath" wrote:
>
> > libav -> x264 -> libav
>
> AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
> library. So theortically (!) this issue could be solved by two separate
> source packages for the x264 frontend and the library.
>
> - Fab
2012/5/4 Игорь Пашев
> x11-utils
xfonts-utils
When I meet circular build deps:
1. Just get sources and try to build, satisfying what possible.
Some deps required for docs or tests and may be ignored for the first time.
2. If a build dep is really required to build (I remember x11-utils), I
install it separately
from sources into /usr/local
annot do a clean build of libav without having
>> > libav compiled already (for opencv).
>> > I don't see this as a viable solution, especially if in the future the
>> > epoch is raised bringing again conflicts between the old libav libraries
>> > and the new
especially if in the future the
> > epoch is raised bringing again conflicts between the old libav libraries
> > and the new one.
> >
> > --
> > Pino Toscano
>
> I'm not entirely certain how build circular dependency issues like this
are resolved. Perhaps we
On Thu, Nov 11, 2010 at 10:15:54AM +0100, Ansgar Burchardt wrote:
> Roger Leigh writes:
>
> >> There is a solution to this actually. Create a Packages, Release and
> >> Release.gpg file for the pseudo package and add them as file:// url to
> >> sources.list.d/. Then just apt-get install pseudo-pa
On Wed, Nov 10, 2010 at 05:17:30PM -0500, Andres Mejia wrote:
> On Wed, Nov 10, 2010 at 2:57 PM, Goswin von Brederlow
> wrote:
> > Roger Leigh writes:
> >
> >> On Wed, Nov 10, 2010 at 01:00:29PM +0100, Goswin von Brederlow wrote:
> >>> Roger Leigh writes:
> >>
> >> The existing approach to dete
Roger Leigh writes:
>> There is a solution to this actually. Create a Packages, Release and
>> Release.gpg file for the pseudo package and add them as file:// url to
>> sources.list.d/. Then just apt-get install pseudo-package.
>
> I'll give that a go, thanks.
You might be interested in the patc
Roger Leigh writes:
> I was considering this earlier, and had this idea:
>
> testing migration currently conflates two separate criteria when
> considering suitability for migration:
>
> ⢠the package is built on all architectures
> ⢠the package meets certain quality criteria such as buggine
lease.gpg file for the pseudo package and add them as file:// url to
>> sources.list.d/. Then just apt-get install pseudo-package.
>
> Another solution is to create a Sources file and use the 'build-dep'
> command from apt-get or aptitude.
Can use a unsigned Sources file
happen in cases where another solution would keep it?
>
> There is a solution to this actually. Create a Packages, Release and
> Release.gpg file for the pseudo package and add them as file:// url to
> sources.list.d/. Then just apt-get install pseudo-package.
Another solution is to create a
Packages, Release and
> Release.gpg file for the pseudo package and add them as file:// url to
> sources.list.d/. Then just apt-get install pseudo-package.
I'll give that a go, thanks.
> >> This destroys the determinicity of build dependencies. So if I say
> >>
> >> B
pendency package as a solution! Currently looking
> at the possibilities here--any thoughts welcome!
Does that actually happen in cases where another solution would keep it?
There is a solution to this actually. Create a Packages, Release and
Release.gpg file for the pseudo package and add them as fil
Roger Leigh writes ("Re: [buildd-tools-devel] testers wanted: sbuild and
build-dependencies"):
> The existing approach to determinism is not to support alternatives
> at all, which is clearly not ideal. While I don't think we should
> be encouraging the use of alternative
rcumstances yet,
but also available (in git only at present) for testing. The
main issue with apt is getting "apt-get -yf install" to not choose
to remove the dependency package as a solution! Currently looking
at the possibilities here--any thoughts welcome!
> This destroys the determinic
esolving doesn't result in inconsistent
> installation of packages and hence inconsistent library dependencies
> or break building of any packages etc.
Yet another or did he take the one from pbuilder?
This destroys the determinicity of build dependencies. So if I say
Build-Depends:
Hi folks,
sbuild 0.60.4 has just been uploaded to unstable, and we would very
much like to get some feedback about a new feature it includes.
If you're a user of sbuild, this means you!
When sbuild builds a source package, either locally or on a buildd,
it uses a "dependency resolver" to determin
> To work properly with sbuild, packages should be build depending on
> "automake | automaken", as in they should first list a real package,
> then the virtual package. sbuild will only consider the first
> of the alternatives.
In such cases (and if there's no virtual package involved) sbuild wi
On Sat, Oct 27, 2007 at 06:50:55PM +0100, Ian Jackson wrote:
> I've been working on getting my automatic package tester working.
> It's currently running but I've redirected its automatic bug
> submission emails to me, while I make sure that the bugs it reports
> are correct.
>
> One common proble
y decide what to use.
Is this a bug in the package(s); or is it a bug in apt ? After all if
it really doesn't matter which version is installed and the resulting
binaries will be correct, then any version will do.
I think that we ought really to be sure what the build-dependencies
mean, so I th
Frank Küster <[EMAIL PROTECTED]> wrote:
> Dear fellow developers,
>
> the Debian TeX Task force is currently preparing an upload of TeX Live
> 2007 to unstable. With this version, teTeX will vanish as a separate
> package and only continue to exist as transitional packages.
I must apologize for
On Tue, Dec 12, 2006 at 09:43:52AM -0700, Shaun Jackman wrote:
> Why is the buildd not finding debhelper?
There appears to have been a combination of a locking bug in sbuild,
together with multiple instances of sbuild running on some buildds, that
was causing problems like this.
--
Steve Langase
Why is the buildd not finding debhelper?
Thanks,
Shaun
http://buildd.debian.org/build.php?&pkg=monotone&ver=0.31-3&arch=powerpc&file=log
Automatic build of monotone_0.31-3 on malo by sbuild/powerpc 99.99
Build started at 20061205-2149
...
** Using build dependencies supplied b
Jon Dowland <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2006 at 01:48:45PM +0200, Goswin von
> Brederlow wrote:
>> As to your real problem. I was playing around with
>> building dummy packages (src-) on the fly from the
>> Sources file that depends on all Build-Depends.
>
> Me too!
>
>> The idea
On Thu, Oct 26, 2006 at 01:48:45PM +0200, Goswin von
Brederlow wrote:
> As to your real problem. I was playing around with
> building dummy packages (src-) on the fly from the
> Sources file that depends on all Build-Depends.
Me too!
> The idea was that you would 'aptitude install src-foo' to
> i
1 - 100 of 148 matches
Mail list logo
