On Sat, Nov 12, 2016 at 10:43:11PM +0100, Michael Banck wrote:
> Hi Santiago,
>
> On Wed, Nov 09, 2016 at 05:38:43PM +0100, Santiago Vila wrote:
> > The problem seems to be in the install target of the top-level
> > Makefile, which reads like this:
>
> Thanks a lot for tracking this down, I've
Hi Santiago,
On Wed, Nov 09, 2016 at 05:38:43PM +0100, Santiago Vila wrote:
> The problem seems to be in the install target of the top-level
> Makefile, which reads like this:
Thanks a lot for tracking this down, I've forwarded it upstream and
uploaded a new revision with your patch.
Does -3
Hi Santiago
On 9 November 2016 at 18:38, Santiago Vila wrote:
> There are severl problems here:
>
> * The directory "test-suite" should be excluded but it isn't.
>
> * The output of "find" depends on filesystem ordering, it may be anything.
>
> * The "cp" commands are
Hi.
The problem seems to be in the install target of the top-level
Makefile, which reads like this:
install : touch-dummy
@if test -d bin ; then mkdir -p $(DESTDIR)$(bindir) ; \
for x in `find . -path ./test-suite -prune -o -name *.x -type f` ; do \
cp $$x
On Wed, Nov 09, 2016 at 02:55:14PM +0200, Graham Inggs wrote:
> Just to be clear:
> - the build is always successful on some autobuilders
> - the build randomly fails on the other autobuilders
>
> Is that right?
It is actually "better" than that: On the machine where it fails, it
always fails
Hi Santiago
On 9 November 2016 at 13:41, Santiago Vila wrote:
> Hi. I have taken a look at the build logs and I have to agree that
> downgrading is the only sensible thing to do for now.
I'm glad we could agree on that.
> I naively thought that this would be easy to reproduce,
> I'm lowering the severity of this bug for now.
Hi. I have taken a look at the build logs and I have to agree that
downgrading is the only sensible thing to do for now.
I naively thought that this would be easy to reproduce, but the
randomness does not happen in each autobuilder. Instead, the
On Tue, Nov 08, 2016 at 12:05:31PM +0200, Graham Inggs wrote:
> On 17/10/2016 19:25, Santiago Vila wrote:
> > Note: It does not always fail for me.
> >
> > I tried 13 times so far. It failed 11 times.
>
> It built 3 times in a row for me on amd64.
A successful build in your machine does not
Control: severity -1 normal
Hi Santiago
On 17/10/2016 19:25, Santiago Vila wrote:
Note: It does not always fail for me.
I tried 13 times so far. It failed 11 times.
It built 3 times in a row for me on amd64.
As you noted, it also built on the buildds, except on ppc64.
Version 6.0-2 seems
Note: It does not always fail for me.
I tried 13 times so far. It failed 11 times.
Status: failed espresso_6.0-2_amd64-20161013T061302Z
Status: failed espresso_6.0-2_amd64-20161013T152415Z
Status: failed espresso_6.0-2_amd64-20161013T152515Z
Status: failed
Note: A similar failure happened on the ppc64 autobuilder:
https://buildd.debian.org/status/package.php?p=espresso
So I guess this is not architecture-related.
What kind of bug makes "make install" to fail?
A bug in the Makefile?
My autobuilder has a single CPU, maybe that's relevant.
Thanks.
Package: src:espresso
Version: 6.0-2
Severity: serious
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
12 matches
Mail list logo