Monday 22 May 2006 19:18 skrev Bastian Venthur: > Magnus Holmgren wrote: > > Because of the lack of "touch patch-stamp", or anything else that creates > > patch-stamp, in the patch-stamp target, patch-stamp, configure-stamp, and > > build-stamp are redone when debian/rules binary is called. That might not > > be so bad in itself, but the upstream Makefile then tries to create 20 > > directories that already exist, failing miserably. > > Are you sure this is due the lack of patch-stamp? I've encountered this > bug before too but I thought I fixed it with the .NOTPARALLEL target in > debian/rules. The problem was (and still is, as it seems) that this bug > is very hard to reproduce.
I believe you should be able to download a source package with apt-get source,
possibly fix build dependencies with apt-get build-dep, and then build the
binary packages with dpkg-buildpackage -rfakeroot. When I do that, what very
deterministically happens is this (after dpkg-buildpackage calls
dpkg-source):
* dpkg-buildpackage runs debian/rules build,
* which runs make.
* Makefile creates the output directories.
* Makefile makes the various themes (make -C blue_src etc.)
* dpkg-buildpackage runs debian/rules binary
* which depends on (binary-indep binary-arch), which depend on build,
which depends (via build-stamp, configure-stamp, and patch) on
patch-stamp, which is never created as a file,
* so patching, configuring, and building is done once again,
* and Makefile tries to create the same directories again.
> I just ran pdebuild 10 times with and 10 times without your suggested
> change and had not one single occurrence of the bug you described.
I'm not familiar with pdebuild. It's possible that it calls debian/rules goals
differently. Just calling debian/rules clean followed by debian/rules binary
works, for example.
> I know this bug too, but I'm currently not able to reproduce. It looks
> like some race condition or something.
>
> > So, in debian/rules,
> >
> > touch patch-stamp
> >
> > at the end of the patch-stamp target should suffice.
>
> Although I doubt that this will fix the bug, I agree that a touch
> patch-stamp is missing.
>
> So what do we do now? From my point of view, the missing patch-stamp
> itself is not a grave bug (although it *is* missing) and the FTBFS seems
> to be unrelated to the patch-stamp issue -- at least for me, since I'm
> not able to reproduce.
>
> On the other side: If you can reproduce this bug (e.g. it happens all
> the time without patch-stamp) and could confirm that adding your patch
> closes the bug, I'd be convinced.
>
> If you cannot reproduce this bug deterministically too, I'd suggest to
> downgrade this bug to minor since the missing patch-stamp does not cause
> a FTBFS for CC and hunt for the other bug in a separate bug report.
Adding "touch patch-stamp" very deterministically fixes the problem for me
(i.e. dpkg-buildpackage works), since the build target isn't called again.
But upstream should also fix the Makefile.
--
Magnus Holmgren [EMAIL PROTECTED]
(No Cc of list mail needed, thanks)
pgpPHvLS5K39x.pgp
Description: PGP signature
