Le vendredi 14 novembre 2014 à 07:03 +0800, Paul Wise a écrit :
> On Fri, Nov 14, 2014 at 6:19 AM, Jérémy Lal wrote:
> > Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit :
> >> On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote:
> >>
> >> > As a workaround, this is the reason why arch:all
On Fri, Nov 14, 2014 at 6:19 AM, Jérémy Lal wrote:
> Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit :
>> On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote:
>>
>> > As a workaround, this is the reason why arch:all nodejs modules have a
>> > build-dependency on nodejs - it prevents them t
Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit :
> On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote:
>
> > As a workaround, this is the reason why arch:all nodejs modules have a
> > build-dependency on nodejs - it prevents them to be available on arches
> > where nodejs isn't.
>
> I
On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote:
> As a workaround, this is the reason why arch:all nodejs modules have a
> build-dependency on nodejs - it prevents them to be available on arches
> where nodejs isn't.
I think you meant dependency, a build-dependency would not achieve that.
--
Le mercredi 12 novembre 2014 à 18:42 +0800, Paul Wise a écrit :
> On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote:
>
> > This is a bug, I’ve seen this affect buildd dependency resolution,
> > and anyway, if it’s not installable everywhere, why is it arch:all?
>
> I would guess that uninsta
On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote:
> This is a bug, I’ve seen this affect buildd dependency resolution,
> and anyway, if it’s not installable everywhere, why is it arch:all?
I would guess that uninstallable arch:all things happens when they
depend on non-portable things. For
On Fri, 7 Nov 2014, Ralf Treinen wrote:
> architecture-specific. The issue of architecture=all packages that
> are not installable on some architecture can IMHO not be solved with
> our current setup which makes architectures=all available on every
> architecture.
This is a bug, I’ve seen this a
On 09/11/14 08:38, Ralf Treinen wrote:
> On Fri, Nov 07, 2014 at 06:11:45PM +, Simon McVittie wrote:
>> On 07/11/14 16:15, Ralf Treinen wrote:
>>> There is only one package in the "each" category, and this is a false
>>> positive due to multiarch: lib32nss-mdns, which exists only on amd64
>>> (
On Sat, Nov 08, 2014 at 12:39:41PM +, Holger Levsen wrote:
> Hi Ralf,
>
> On Freitag, 7. November 2014, Ralf Treinen wrote:
> > The issue of architecture=all packages that
> > are not installable on some architecture can IMHO not be solved with
> > our current setup which makes architectures=
On Fri, Nov 07, 2014 at 06:11:45PM +, Simon McVittie wrote:
> On 07/11/14 16:15, Ralf Treinen wrote:
> > There is only one package in the "each" category, and this is a false
> > positive due to multiarch: lib32nss-mdns, which exists only on amd64
> > (this is why it shows up in the each catego
Hi Ralf,
On Freitag, 7. November 2014, Ralf Treinen wrote:
> > The bad weather in
> > https://qa.debian.org/dose/debcheck/testing_main/index.html is still
> > surprising to see, at this point...
> not at all ! The weather icons are a bit misleading (this is one reason
> why I wasn't such a big fan
On 07/11/14 16:15, Ralf Treinen wrote:
> There is only one package in the "each" category, and this is a false
> positive due to multiarch: lib32nss-mdns, which exists only on amd64
> (this is why it shows up in the each category) and depends on an i386
> package, which is deliberate in this case.
Hi Holger,
(repliying separately to the two pointes raised by you)
On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote:
> On Mittwoch, 5. November 2014, Ralf Treinen wrote:
> > yes, you did miss something :-)
> > first link on the page: "Non-installable packages"
> > https://qa.debian.
13 matches
Mail list logo
