Marco d'Itri <md@Linux.IT> wrote:
> On Dec 02, Daniel Schepler <schepler@math.unipd.it> wrote:
>
>> I finally got through the test builds of all the source packages in sid for
>> i386 using dpkg-buildpackage -j3 on a dual core machine. The results as
>> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .
>
> Can you explain the meaning of this failure and how it should be fixed?
>
> make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
Quoting from http://lists.samba.org/archive/distcc/2004q1/002160.html
There are (at least?) three reasons why this might be so:
1) The parent make didn't realize that the child process it was
invoking was actually a "make" program. In this case, it won't
allow the child to connect to the jobserver. This is typically
because the command to invoke the child uses "make" or similar
rather than the correct $(MAKE). See the docs on the "+" token to
understand the algorithm GNU make uses to determine if the child is
a sub-make or not.
Bye, Jörg.
--
Wenn du nur einen Hammer hast, sieht jedes Problem aus wie ein Nagel.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 10:07 AM
"Bernhard R. Link"
Parallel build results
* Marco d'Itri <md@Linux.IT> [071203 09:53]:
> Can you explain the meaning of this failure and how it should be fixed?
>
> make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
That usually means a new make is started without the calling make
realizing it is starting a make. In most of the cases that means that
some makefile (like debian/rules) is calling make instead of $(MAKE).
There are also some special other cases (like when $(MAKE) is used, but not
directly but indirectly referenced, then this might be fixed by
prefixing the command with a +, but beware of the other meanings this
has.), which normally dictate a closer look, as when something is doing
such absurdities, there might be some reason to it. (well, or not)
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 10:21 AM
"Bernhard R. Link"
Parallel build results
* Patrick Schoenfeld <schoenfeld@in-medias-res.com> [071202 20:43]:
> Relevant parts for detox are:
> /usr/bin/install -c -d /tmp/buildd/detox-1.1.1/debian/tmp/etc
> /usr/bin/install: cannot create regular file
> `/tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample': No such file or
> directory
>
> So I assume the first install command for debian/tmp/etc was not
> successful? I'm not very experienced with parallel builds and I cannot
> reproduce this on my single-core-systems. So: Is there some
> documentation or hints on how to make package building be parallel-safe?
As you can see, install says it needs install-base and install-sample-config
but install-sample-config does not say it wants install-base to be run before
it is run, so nothing enforces sysconfigdir is actually created.
Only when install-safe-config is run while install-base had not yet had enough
time to complete directory creating, this produces an error.
The fix for this problem is just to tell install-safe-config (and the other
install-* stuff needing a directory) to either create the directory first or
depend on the rule that creates it.
Catching those race conditions is hard, even a -jN run might just not trigger it
if the directory creating is fast enough. Perhaps someone would like to write a
patched make that does reorderable target in reversed order and try to build the
whole archive with it (and -j1), to catch those problems more reliable.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 10:29 AM
Simon Josefsson
Parallel build results
Daniel Schepler <schepler@math.unipd.it> writes:
> I finally got through the test builds of all the source packages in sid for
> i386 using dpkg-buildpackage -j3 on a dual core machine. The results as
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .
Which said:
shishi: succeeded, but with jobserver warnings
and in the logs:
...
make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent
make rule.
...
I believe I've fixed this in the debian package CVS. The problem was
use of 'make' rather than '$(MAKE)' in rules.
Thanks,
Simon
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 11:43 AM
Daniel Schepler
Parallel build results
On Monday 03 December 2007 05:11:35 am Tim Cutts wrote:
> Well, am-utils lists as building broken packages, but when I looked at
> the log, it was just that the parallel build had produced the multiple
> binary packages in a different order from the serial build. At least,
> that's my interpretation of the following from debdiff:
>
> Files moved or copied from at least TWO packages or to at least TWO
> packages
> ---------------------------------------------------------------------------
>- -rw-r--r-- root/root DEBIAN/control
> From packages: am-utils-doc, am-utils, libamu4, libamu-dev
> To packages: am-utils-doc, libamu4, libamu-dev, am-utils
> -rw-r--r-- root/root DEBIAN/md5sums
> From packages: am-utils-doc, am-utils, libamu4, libamu-dev
> To packages: am-utils-doc, libamu4, libamu-dev, am-utils
> -rwxr-xr-x root/root DEBIAN/postinst
> From packages: am-utils-doc, am-utils, libamu4
> To packages: am-utils-doc, libamu4, am-utils
> -rwxr-xr-x root/root DEBIAN/postrm
> From packages: am-utils, libamu4
> To packages: libamu4, am-utils
>
> Or does that mean something more basic that's wrong with the packages?
So the Depends line got changed in the parallel build.
--
Daniel Schepler
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 12:28 PM
Tim Cutts
Parallel build results
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 3 Dec 2007, at 12:43 pm, Daniel Schepler wrote:
Control files of package am-utils: lines which differ (wdiff format)
--------------------------------------------------------------------
Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (>=
2.6.1-1),
libgdbm3, libhesiod0, libldap2 (>= 2.1.17-1), libwrap0, perl,
debconf (>=
1.2.0), ucf, debianutils (>= 1.6)
So the Depends line got changed in the parallel build.
Sure, yes, I realise that one. Don't know why it's happening though.
It may change though as I make changes do deal with the shlibdeps
stuff that's also going on at the moment, so I'm going to deal with
that first, and see whether this problem persists afterwards.
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 12:30 PM
Patrick Schoenfeld
Parallel build results
Hi Bernhard,
On Mon, Dec 03, 2007 at 12:21:45PM +0100, Bernhard R. Link wrote:
> The problem is in upstream's Makefile.in:
thanks for the good explanation. Also to Daniel whose hint already pointed me
in the right direction. Its already fixed in latest upload.
Thanks,
Best Regards
Patrick
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-03-2007, 10:57 PM
Anthony Towns
Parallel build results
On Mon, Dec 03, 2007 at 01:28:08PM +0000, Tim Cutts wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> On 3 Dec 2007, at 12:43 pm, Daniel Schepler wrote:
>> Control files of package am-utils: lines which differ (wdiff format)
>> --------------------------------------------------------------------
>> Depends: libamu4 (= 6.1.5-7), portmap, {+libamu4,+} libc6 (>= 2.6.1-1),
>> libgdbm3, libhesiod0, libldap2 (>= 2.1.17-1), libwrap0, perl, debconf (>=
>> 1.2.0), ucf, debianutils (>= 1.6)
>> So the Depends line got changed in the parallel build.
> Sure, yes, I realise that one. Don't know why it's happening though.
Isn't that just due to dpkg changes?
(1.14.8) unstable; urgency=low
[ Raphael Hertzog ]
* Switch perl programs to use the new Dpkg:eps module. This changes the
behaviour of dpkg-gencontrol and dpkg-source which will rewrite and
simplify dependencies and build dependencies as possible. Multiple
dependencies on the same package are replaced by their intersection.
Closes: #178203, #186809, #222652
At the moment, dpkg 1.14.7 is in testing, dpkg 1.14.12 in unstable.
Cheers,
aj
12-30-2007, 11:43 AM
Brendan O'Dea
Parallel build results
On Sun, Dec 02, 2007 at 11:13:53PM +0000, Ben Hutchings wrote:
>It appears that ExtUtils::MakeMaker, a standard Perl module commonly
>used to generate Makefiles for Perl modules, emits the rule:
>
>install :: all pure_install doc_install
>
>This appears to account for the failure of some of my Perl packages, and
>probably many others. This should be fixed in MakeMaker, not in the
>packages that use it.
About the only option I can see is to use something like:
install :: all
$(MAKE) pure_install doc_install
which I'm not terribly keen on. I'm open to better suggestions.
--bod
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-30-2007, 12:17 PM
Michael Tautschnig
Parallel build results
> On Sun, Dec 02, 2007 at 11:13:53PM +0000, Ben Hutchings wrote:
> >It appears that ExtUtils::MakeMaker, a standard Perl module commonly
> >used to generate Makefiles for Perl modules, emits the rule:
> >
> >install :: all pure_install doc_install
> >
> >This appears to account for the failure of some of my Perl packages, and
> >probably many others. This should be fixed in MakeMaker, not in the
> >packages that use it.
>
> About the only option I can see is to use something like:
>
> install :: all
> $(MAKE) pure_install doc_install
>
> which I'm not terribly keen on. I'm open to better suggestions.
>
I don't actually remember the part of this discussion where the real cause of
the problem with the above rule was discussed, but in case it is about some
dependencies between the rules (which is the most likely IMHO), then it should
really be fixed as follows
doc_install:
...
pure_instal: doc_install
...
all: pure_install
...
install:: all
...
This is not a hack but instead the only way of properly fixing the problem (and
in fact the parallel builds then only made the bug visible...).
Parallel build results
eps module. This changes the
