On Thu, 2013-07-18 at 22:59 +0200, Daniel Pocock wrote:
>
> On 18/07/13 22:44, Adam D. Barratt wrote:
> > On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote:
> >> I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
> >> to various dependencies:
> >> https://buildd.debian.or
On 18/07/13 22:44, Adam D. Barratt wrote:
> On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote:
>> I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
>> to various dependencies:
>> https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
>>
>> and it appears t
On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote:
> I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
> to various dependencies:
> https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
>
> and it appears these dependencies have been unavailable for a long
On Thu, Jul 18, 2013 at 12:46:28PM +0200, Daniel Pocock wrote:
> I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
> to various dependencies:
> https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
I see it built immediately on kfreebsd-*, what's the problem?
Daniel Pocock, le Thu 18 Jul 2013 12:46:28 +0200, a écrit :
> To avoid causing delays for users who want the fixes in testing, I'm
> tempted to just change "Architecture: any" and cut out those other
> platforms.
I'd say there is no need for this. If *your* package is supposed to
work on all plat
I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
to various dependencies:
https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
and it appears these dependencies have been unavailable for a long time.
The bottom line is that urgent fixes in the package are
Steve Langasek wrote:
> On Mon, Jan 09, 2006 at 02:37:53PM +0100, Frank Küster wrote:
>
>>Matthijs Mohlmann <[EMAIL PROTECTED]> wrote:
>
>
>>>I don't know where to send this else, so forgive me if this is the wrong
>>>mailinglist.
>
>
>>>See:
>>>http://buildd.debian.org/fetch.php?&pkg=pdns&ver
Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 10, 2006 at 12:24:47PM +0100, Frank Küster wrote:
>> Steve Langasek <[EMAIL PROTECTED]> wrote:
>
>> > Historically such
>> > problems were unpleasantly frequent on buildds due to a combination of
>> > buggy
>> > postrm scripts, and a bug in
On Tue, Jan 10, 2006 at 12:24:47PM +0100, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Historically such
> > problems were unpleasantly frequent on buildds due to a combination of buggy
> > postrm scripts, and a bug in dpkg's rollback support when calling dpkg
> > --purge fo
LaMont Jones <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 10, 2006 at 11:08:14AM +0100, Frank Küster wrote:
>> Steve Langasek <[EMAIL PROTECTED]> wrote:
>> > or a bug in some
>> > maintainer script or other;
>> How a bug in a maintainer script could have the result that installing
>> an arch-all packa
On Tue, Jan 10, 2006 at 11:08:14AM +0100, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > or a bug in some
> > maintainer script or other;
> How a bug in a maintainer script could have the result that installing
> an arch-all package fails because an other arch-all package is no
Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 10, 2006 at 11:08:14AM +0100, Frank Küster wrote:
>
>> It *seems* it has been fixed; but I don't know whether it has just
>> disappeared, or has been fixed by human intervention, and if yes by
>> which. Since the first may be true, it might
On Tue, Jan 10, 2006 at 11:08:14AM +0100, Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 09, 2006 at 02:37:53PM +0100, Frank Küster wrote:
> >> The same happened to the planner package, and has been reported as
> >> #344538. It seems that hppa buildd is broken, do
Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 09, 2006 at 02:37:53PM +0100, Frank Küster wrote:
>> The same happened to the planner package, and has been reported as
>> #344538. It seems that hppa buildd is broken, don't know yet whether
>> the buildd admin (Lamont) or anybody of the de
On Mon, Jan 09, 2006 at 02:37:53PM +0100, Frank Küster wrote:
> Matthijs Mohlmann <[EMAIL PROTECTED]> wrote:
> > I don't know where to send this else, so forgive me if this is the wrong
> > mailinglist.
> > See:
> > http://buildd.debian.org/fetch.php?&pkg=pdns&ver=2.9.19-2&arch=hppa&stamp=1135294
Matthijs Mohlmann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I don't know where to send this else, so forgive me if this is the wrong
> mailinglist.
>
> See:
> http://buildd.debian.org/fetch.php?&pkg=pdns&ver=2.9.19-2&arch=hppa&stamp=1135294848&file=log&as=raw
>
> [..]
[...]
> As you can see, tetex-base
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I don't know where to send this else, so forgive me if this is the wrong
mailinglist.
See:
http://buildd.debian.org/fetch.php?&pkg=pdns&ver=2.9.19-2&arch=hppa&stamp=1135294848&file=log&as=raw
[..]
Setting up tetex-base (3.0-11) ...
Removing unch
On Sun, Jul 17, 2005 at 04:28:56PM +0200, Harald Dunkel wrote:
> I know, but as written before, IMHO the abi version number should
> not be encoded in the package name. Usually you just get a new
> abi, but no new functionality, so why introduce a new name? Just
> to work around the limitations of
Harald Dunkel <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> Harald Dunkel <[EMAIL PROTECTED]> writes:
>>
>>>
>>>But I can follow your argument. Dpkg should allow installing
>>>different C++ abis on the same machine. Only within each
>>>dependency chain the abi version number must b
Goswin von Brederlow wrote:
> Harald Dunkel <[EMAIL PROTECTED]> writes:
>
>>
>>But I can follow your argument. Dpkg should allow installing
>>different C++ abis on the same machine. Only within each
>>dependency chain the abi version number must be unique, so
>>it should become some kind of packag
Harald Dunkel <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>>
>> A single C++-ABI package would just mean that all c++ packages are
>> kept back (or removed) from the very start of the c++ transition up to
>> the very end. There will be a lot of packages at the end of the
>> dependen
Goswin von Brederlow wrote:
>
> A single C++-ABI package would just mean that all c++ packages are
> kept back (or removed) from the very start of the c++ transition up to
> the very end. There will be a lot of packages at the end of the
> dependency chains that you don't have installed and that w
Harald Dunkel <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow wrote:
>> yes
>>
>> welcome to the c++ abi transition
>>
>>
> Maybe this has been suggested before, but...
>
> Probably more C++ abi changes will follow. To support a
> smooth migration I would like to suggest to create empty
> pa
Goswin von Brederlow wrote:
> yes
>
> welcome to the c++ abi transition
>
>
Maybe this has been suggested before, but...
Probably more C++ abi changes will follow. To support a
smooth migration I would like to suggest to create empty
packages describing the C++ abis.
A package maintainer could
On Sat, 22 Dec 2001 01:38:44 +0100
"Nicolas Chauvat" <[EMAIL PROTECTED]> wrote:
> Anyhow, my pet project for tonight was to write such a graph checker.
I (and others i know of) have thought about this problem, it is an
intersting problem, i dont think anybody has come up with a good
solution yet.
in consistency.
I was not advocating the use of some automatic tool to keep testing in
consistency.
My idea was to detect dependency problems in order to file bugs if
needed and let package maintainers fix them, not to prevent packages to
enter testing in case they were to introduce dependency c
* Nicolas Chauvat <[EMAIL PROTECTED]> [011222 01:53]:
> [...] (I am using testing). [...]
> What I call a conflict dependency problem is something like (A conflicts
> with B and B depends on A). I saw at least one case where this was on
> purpose to facilitate upgrade, but I would say that it is
A few packages in potato seem to have dependency problems at the moment.
This is by no means an exhausive list. This is just a general heads-up. I
will file bugs with the packages if similar ones have not yet been filed.
emacs20: Depends: liblockfile0 but it is not installable
While testing the upgrading of rex to hamm I have discovered
several problems or possible bugs. I will post each of these as
separate messages, and ask if anyone else has encountered them, and if
they should be reported as bugs.
Timezone:
Version 7.48-3 of timezone was installed and tim
29 matches
Mail list logo
