Created attachment 179384 [details] patch rxtx-openjdk8 (comms/rxtx) fails to make package unless MAKE_JOBS_UNSAFE is turned on (see attached poudriere build log). While we're here define LICENSE.
Created attachment 179385 [details] podriere build log showing build failure
*** Bug 216557 has been marked as a duplicate of this bug. ***
Would it be possible to share your contents of /etc/make.conf on the compile host in question please? Kr, James
LICENSE defined in bug #216248.
Comment on attachment 179384 [details] patch LICENSE defined in dependency added.
Created attachment 179387 [details] make.conf Here's a make.conf I copied out of the jail I got with "poudriere bulk -i ..."
Many Thanks; looking into issue now. Kr, James
(In reply to leres from comment #0) Have looked at the log you have supplied. With the EPOCH 4 patch submitted in bug #216248 applied, the reported issue is not seen (confirmed today with a "bulk -c" being issued on poudriere). On doing a diff between the working (bug #216248) and failed (this report) log I noticed: - Non-default port options set on zinc.ee.lbl.gov (e.g. "png" being built on zinc) - OS 10.3-p16 on zinc, OS 11.0-p7 on radon - custom make options set on zinc Will run a new build on a 10.3 jail to see if I can replicate the issue shown. I wonder if this is an issue only seen on <11.0?! Should have answer to above question in about 10 hours...
Just built on fresh FreeBSD 10.3-p16 without any build options set, without issue. Going to add your make.conf settings in to see if that leads to an error, but right now I cannot replicate the issue you are experiencing.
Wow! Your options file rocks; llvm39 with -g set results in llvm39 package which is over 100GB in size!! (Delay in responding due to my build machine having had a full workout!) However, I cannot recreate the issue you have posted; Can I have some more information please? Can you provide a copy of the following from the build machine (not inside the jail) please: grep -v # /etc/make.conf grep -v # /usr/local/etc/poudriere.conf Also can you confirm the command line you are using to launch poudriere when experiencing this error please? Kr, James.
Created attachment 179777 [details] JCE - comms/rxtx (epoch 3) build log from a clean ports build FreeBSD 10.3 amd64 using LBL poudriere make file fresh clean ports tree latest ports version of openJDK v8 rxtx-openjdk8-2.2p2_3.log Working, no build issue seen.
Created attachment 179778 [details] JCE - comms/rxtx (epoch 4) build log from a clean ports build (4 FreeBSD 10.3 amd64 using LBL poudriere make file fresh patched ports tree with Epoc 4 (see bug #216248) latest ports version of openJDK v8 rxtx-openjdk8-2.2p2_3.log Working, no build issue seen. Do need information requested in comment #10
Created attachment 179779 [details] JCE - poudriere.conf (working) Attached working /usr/local/etc/poudriere.conf file. (Also noted is that FreeBSD Jenkins build cluster has been compiling EPOCH 3 for sometime without issue.) Maybe the issue is local to the "zinc" build machine? Further information from reporter of issue required to recreate; not doubting issue exists, but need to understand how to replicate the issue to confirm resolution is appropriate.
I removed /etc/make.conf and the make.conf used with my poudriere build jail and then started commenting out non-default lines in my poudriere.conf. Looks like PRIORITY_BOOST causes the problem. I'll attach a diff.
Created attachment 179927 [details] poudriere.conf diff against .sample that causes build failure
Status?
Created attachment 190498 [details] podriere build log showing build failure I still see frequent poudriere build errors without MAKE_JOBS_UNSAFE=yes: Error: cannot access gnu.io.RS485.MonitorThread see attached build log.
Cannot read attachment. How is it encoded?
It's gzip'ed.
Reporter is committer, assign accordingly
Comment on attachment 179384 [details] patch Approved by: koobs (ports) @Craig Please include the error message in the commit log message that has been observed without this patch added. (ie with parallel builds) and merge to quarterly too
This issue, while technically a maintainer timeout (1+ years since last maintainer response, 10 months since last comment), we as developers/triagers should remember to set maintainer-feedback to ? <maintainer-email> in cases that we want/need feedback, or the maintainer-approval flag on attachments where we want approval, so that we have 'explicitly requested it', rather than left it implicit. Once ? <maintainer-email> is set on a flag, you can then: Approved by: portmgr (maintainer timeout: > 2 weeks) at your leisure.
> Approved by: koobs (ports) > > @Craig Please include the error message in the commit log message > that has been observed without this patch added. (ie with parallel > builds) and merge to quarterly too Here's the error: java.util.zip.ZipException: attempt to write past end of STORED entry at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:336) at sun.tools.jar.Main.copy(Main.java:880) at sun.tools.jar.Main.copy(Main.java:894) at sun.tools.jar.Main.addFile(Main.java:841) at sun.tools.jar.Main.create(Main.java:545) at sun.tools.jar.Main.run(Main.java:214) at sun.tools.jar.Main.main(Main.java:1288) gmake[1]: *** [Makefile:613: /wrkdirs/usr/ports/comms/rxtx/work/rxtx-2.2pre2/gnu/io/RXTXPort.class] Error 1 gmake[1]: *** Waiting for unfinished jobs.... > This issue, while technically a maintainer timeout (1+ years since > last maintainer response, 10 months since last comment), we as > developers/triagers should remember to set maintainer-feedback > to ? <maintainer-email> in cases that we want/need feedback, or > the maintainer-approval flag on attachments where we want approval, > so that we have 'explicitly requested it', rather than left it > implicit. I know to do this now (set maintainer-feedback ?) but I was not a committer when I submitted this PR! > Once ? <maintainer-email> is set on a flag, you can then: > > Approved by: portmgr (maintainer timeout: > 2 weeks) Is it ok for me to move forward with this change?
Hi Craig, Congratulations on getting your comit bit! Thank you for progressing this one, it was something I could not replicate on the hardware I have available (I only have 16 core servers, not 48 core if memory serves correct). I indeed missed your update about PRIORITY_BOOST but if you are can confirm that the change resolves the issue you are experiencing on "zinc" then I see no reason why not. The only comment I would venture is attaching a copy of the build log that successfully works on your system, but that would be more for historic reference than anything else. Thank you for comming back to this issue. Kindest regards, James.
Hi Craig, One other thought: Is the PORTVERSION (Epoch) value going to be bumped to 5 as it is not shown in the current different file please? Kr, James
A commit references this bug: Author: leres Date: Thu Feb 14 01:05:58 UTC 2019 New revision: 492894 URL: https://svnweb.freebsd.org/changeset/ports/492894 Log: Solve occasional poudriere build failures by adding MAKE_JOBS_UNSAFE. Sample poudriere build error without MAKE_JOBS_UNSAFE: Error: Could not find class file for 'gnu.io.Raw'. gmake[1]: *** [Makefile:613: /wrkdirs/usr/ports/comms/rxtx/work/rxtx-2.2pre2/gnu/io/NoSuchPortException.class] Error 1 PR: 216558 Reviewed by: mat, matthew (mentor) Approved by: mat, koobs (maintainer), matthew (mentor) Differential Revision: https://reviews.freebsd.org/D18999 Changes: head/comms/rxtx/Makefile