while you should be overriding -j# on `emake` lines, if you do want to tweak it via MAKEOPTS, you should be appending, not clobbering the variable broken code: app-crypt/ophcrack/ophcrack-3.0.1-r1.ebuild:42: MAKEOPTS="-j1" emake || die "Failed to make samdump" app-crypt/ophcrack/ophcrack-2.4.ebuild:36: MAKEOPTS="-j1" emake || die "Failed to make samdump" app-crypt/ophcrack/ophcrack-2.4.ebuild:41: MAKEOPTS="-j1" emake || die "Failed to make bkhive2" app-crypt/ophcrack/ophcrack-3.0.1.ebuild:42: MAKEOPTS="-j1" emake || die "Failed to make samdump" app-crypt/ophcrack/ophcrack-3.0.ebuild:42: MAKEOPTS="-j1" emake || die "Failed to make samdump" app-crypt/ophcrack/ophcrack-3.0.ebuild:47: MAKEOPTS="-j1" emake || die "Failed to make bkhive2" app-crypt/ophcrack/ophcrack-2.4.1.ebuild:36: MAKEOPTS="-j1" emake || die "Failed to make samdump" app-crypt/ophcrack/ophcrack-2.4.1.ebuild:41: MAKEOPTS="-j1" emake || die "Failed to make bkhive2"
Ok, thanks for the note. What's the best way of fixing this? I looked around in various ebuilds and people seemed to be using "emake -j1" (which I hadn't heard of, but figured existed based on what you said). Unfortunately, repoman (2.2_rc17) seems to have a specific rule against that: ebuild.minorsyn 2 app-crypt/ophcrack/ophcrack-2.4.1.ebuild: Ebuild calls emake -j1 on line: 36 app-crypt/ophcrack/ophcrack-2.4.1.ebuild: Ebuild calls emake -j1 on line: 41 So, is this the recommended best practice for avoiding parallel builds when necessary? If it, who should I tell about removing the minorsyn error? It's really, really confusing to have no warning about MAKEOPTS clobbering, but then a warning about emake -j1, when that seems to be the recommended way of doing things...
by using MAKEOPTS=-j1, you're just avoiding the warning ... it doesnt make the warning any less true `emake -j1` is the correct ebuild syntax. the next step is to fix the package so it builds in parallel. ive opened a bug about repoman detecting MAKEOPTS clobbering ... there wasnt one before because people usually didnt do this ;)
Thanks, the latest version (already in the tree as 3.0.1-r2) no longer has this limitation, so I've trimmed all the old ebuilds, but was leaving around one from the 2.x series just in case. I've added this with emake -j1, but since it's fixed already upstream, that seems like a good solution...
