FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-03-2007, 09:46 AM
Jörg Sommer
 
Default Parallel build results

Hello,

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
 
Old 12-03-2007, 10:07 AM
"Bernhard R. Link"
 
Default 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
 
Old 12-03-2007, 10:21 AM
"Bernhard R. Link"
 
Default 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?

The problem is in upstream's Makefile.in:

install: install-base install-safe-config install-sample-config

install-base: detox
...snip....
${INSTALL} -d ${DESTDIR}${sysconfdir}
...snip

install-safe-config:
@if [ ! -f ${DESTDIR}${sysconfdir}/detoxrc ]; then
${INSTALL} detoxrc ${DESTDIR}${sysconfdir};
..snip...

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
 
Old 12-03-2007, 10:29 AM
Simon Josefsson
 
Default 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
 
Old 12-03-2007, 11:43 AM
Daniel Schepler
 
Default 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?

The relevant difference is actually:

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.
--
Daniel Schepler


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-03-2007, 12:28 PM
Tim Cutts
 
Default 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)

iQEVAwUBR1QEaBypeFo2odvPAQJ1WQgAizNT66pUw/GB72oB8zc1+RVzYrseaRFo
pqZIerbj1mr3G4rKur+wuYAfVEJDR9zgSWEmebwGuklHsa+ezt WcYAgWfD8OBvmD
1vSyhIhfgN0tARQQORX7Ba9G3lM7MnLs8/Rvn3APm0/vacJDDKCucEwdsTqDGpDH
yBh6/9yxF8lLiaumiomGO+vFZTkREXk2CtxNI8nh44ijgYkSdj1QZj9 lZ7cuCC3W
8FnHeLlit9l2K3EVH/0dE/3YcBt2uf3QRfURVKdtPrwpNMuGh0FkuHdScm+BPh/L
oDHtYuSxkElPam3q25a8wno15wVt5qaz+nJ43TtvsC6WGJNxIq Norw==
=I2Ko
-----END PGP SIGNATURE-----


--
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
 
Old 12-03-2007, 12:30 PM
Patrick Schoenfeld
 
Default 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
 
Old 12-03-2007, 10:57 PM
Anthony Towns
 
Default 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
 
Old 12-30-2007, 11:43 AM
Brendan O'Dea
 
Default 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
 
Old 12-30-2007, 12:17 PM
Michael Tautschnig
 
Default 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...).

Best,
Michael
 

Thread Tools




All times are GMT. The time now is 06:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org