On to, 2011-03-17 at 08:32 +, Roger Leigh wrote:
> You can get the same effect with "file" chroots (tarball unpack). It's
> not that slow providing your tarball is really minimal, and it works
> on all architectures. I used this for the whole archive rebuild after
> LVM snapshots oopsed and t
On Thu, Mar 17, 2011 at 08:31:13AM +0100, Cyril Brulebois wrote:
> Hi,
>
> just as a reminder:
>
> Roger Leigh (16/03/2011):
> > OK. I think this is the only known discrepancy between the two
> > resolvers. Given that we now routinely build using minimal clean
> > (cloned) chroots, they will b
Hi,
just as a reminder:
Roger Leigh (16/03/2011):
> OK. I think this is the only known discrepancy between the two
> resolvers. Given that we now routinely build using minimal clean
> (cloned) chroots, they will behave identically in practice because
AFAICT: only possible on Linux f
On Wed, Mar 16, 2011 at 01:07:19AM +0100, Goswin von Brederlow wrote:
> Roger Leigh writes:
>
> > On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
> >> On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
> >> > On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wr
Peter Pentchev writes:
> On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
>> On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
>> > From discussion on IRC earlier this evening, it looks like the most
>> > pragmatic approach will be to get the apt and aptitude sbuild
>> > r
On Wed, Feb 23, 2011 at 11:30:05 +, Roger Leigh wrote:
> +# Should the dependency resolve use alternatives in Build-Depends and
> +# Build-Depends-Indep? By default, only the first alternative will be
> +# used; all other alternatives will be removed. Note that this does
> +# not include arc
On Wed, Feb 23, 2011 at 12:27:00PM +0200, Peter Pentchev wrote:
> On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
> > On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
> > > From discussion on IRC earlier this evening, it looks like the most
> > > pragmatic approach will be
On Wed, Feb 23, 2011 at 12:27:00PM +0200, Peter Pentchev wrote:
> Hi, and apologies in advance if this is a stupid question or if it has
> already been discussed :)
>
> Is it possible that this should lead to problems with further levels of
> package dependencies? E.g. something like that for two
On Wed, Feb 23, 2011 at 11:30:05AM +, Roger Leigh wrote:
> I've now implemented this with the attached patch. If you are happy
> with this behaviour, I'll commit it. Those six lines are equivalent
> to about 300 in the internal resolver! With this change made, would
> you be OK to consider m
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
> On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
> > From discussion on IRC earlier this evening, it looks like the most
> > pragmatic approach will be to get the apt and aptitude sbuild
> > resolvers to strip the alternati
On Wed, Feb 23, 2011 at 10:45:06AM +0100, Philipp Kern wrote:
> On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
> > From discussion on IRC earlier this evening, it looks like the most
> > pragmatic approach will be to get the apt and aptitude sbuild
> > resolvers to strip the alternati
On Tue, Feb 22, 2011 at 10:40:52PM +, Roger Leigh wrote:
> From discussion on IRC earlier this evening, it looks like the most
> pragmatic approach will be to get the apt and aptitude sbuild
> resolvers to strip the alternatives (after arch reduction), which
> will make them behave pretty much
On Tue, Feb 22, 2011 at 03:53:08PM -0800, Russ Allbery wrote:
> Julien Cristau writes:
>
> > I'm still not sure how 'Build-Depends: foo [i386] | bar [amd64]'
> > would make sense (as opposed to making it an 'and').
>
> They're equivalent, so I would view it as intended for human readers, not
> f
Julien Cristau writes:
> I'm still not sure how 'Build-Depends: foo [i386] | bar [amd64]'
> would make sense (as opposed to making it an 'and').
They're equivalent, so I would view it as intended for human readers, not
for computers.
In other words, I see a Build-Depends of:
foo [i386] | b
On Tue, Feb 22, 2011 at 23:26:27 +, Roger Leigh wrote:
> On Wed, Feb 23, 2011 at 12:05:28AM +0100, Julien Cristau wrote:
> > On Tue, Feb 22, 2011 at 22:40:52 +, Roger Leigh wrote:
> >
> > > From discussion on IRC earlier this evening, it looks like the most
> > > pragmatic approach will b
On Tue, 22 Feb 2011 22:28:05 +, Roger Leigh wrote:
> > > perl (>= 5.10) | libmodule-build-perl
> > Could you please explain what's "pointless and/or broken" about that
> > one?
> > (Except that it's old since even lenny has 5.10.0.
> Yes, that's exactly the reason. Because the perl (>= 5.10
On Wed, Feb 23, 2011 at 12:05:28AM +0100, Julien Cristau wrote:
> On Tue, Feb 22, 2011 at 22:40:52 +, Roger Leigh wrote:
>
> > From discussion on IRC earlier this evening, it looks like the most
> > pragmatic approach will be to get the apt and aptitude sbuild
> > resolvers to strip the altern
On Tue, Feb 22, 2011 at 22:40:52 +, Roger Leigh wrote:
> From discussion on IRC earlier this evening, it looks like the most
> pragmatic approach will be to get the apt and aptitude sbuild
> resolvers to strip the alternatives (after arch reduction), which
> will make them behave pretty much e
On Tue, Feb 22, 2011 at 10:21:24PM +0100, Bill Allombert wrote:
> On Tue, Feb 22, 2011 at 06:49:21PM +, Ian Jackson wrote:
> > Roger Leigh writes ("Re: re buildd's resolver and package's build deps"):
> > > I agree that these do serve a useful purpose for these uses, and that
> > > ease of reus
On Tue, Feb 22, 2011 at 10:13:19PM +0100, gregor herrmann wrote:
> On Tue, 22 Feb 2011 17:08:18 +, Roger Leigh wrote:
>
> > · Standard alternative use in the form "concrete|virtual", as used for
> > normal deps on virtual packages. Is this sensible?
> > · Architecture-specific dependencies
20 matches
Mail list logo
