Poudriere bulk failure

just curious how things are going with your package building. working off current I had issues with my favorite ports gettext-runtime and libiconv . They hung poudriere during configure. would not get past "checking if // distinct from /" I'm updating my tree right now to update my bhyve and poudriere jails. to try again, but no luck with poudriere nor poudriere-devel for r346657 . I did notice pkg.freebsd.org does have packages for arm64 for 13 at least for libiconv, but not sure which tree revision they are building against or I'd use it. still not sure its just something I got wrong on my machine. plenty of other packages built fine for me, just those two hung up. also noticed the runaway process timeout setting in poudriere.conf seems to actually use twice the value at lease in poudriere, didn't let it time out in poudriere-devel.

I've also considered dropping back to 12-Stable in at least poudriere jail, but i figure wifi drivers will hit current first, when they come out, and I don't mind experimenting.
 
Just checked on the arm64 ports we built. Keep in mind we are really only building Xorg, Openbox, Chromium, and Fbpanel, and of course all their dependencies.

I didn't run into any of the checking // vs / messages you were receiving but the Chromium build did fail.

qemu: uncaught target signal 4 (Illegal instruction) - core dumped
transport_security_state_generator failed with exit code -4
ninja: build stopped: subcommand failed.
*** error code 1
 
Brian, If you could get Xorg built you made it much further then I could my first stab. but good to here things went reasonably well for you.

Acheron, once again you rock, libiconv built fine with that tip. Wish I found it, maybe have to go back to google over duckduckgo... Now I'll have to read up on poudriere hooks to make sure this stays set for me between ports updates on the off change config.site is changed upstream in the future. or as i look over the available triggers a simple sh script for my poudriere ports update to check for it being set after the update. I'm glad I didn't try to skip this check by finding out a way to force "cross_building=yes" which would make the test basically do the same thing according to the m4 macros. Course that method would likely have broken all sorts of other things in different ways. That was the only thing I could come up with the other night, but it seemed like a bad idea all around.

Here's to giving Xorg another go...
 
Brian546 said:
Just checked on the arm64 ports we built. Keep in mind we are really only building Xorg, Openbox, Chromium, and Fbpanel, and of course all their dependencies.

I didn't run into any of the checking // vs / messages you were receiving but the Chromium build did fail.

qemu: uncaught target signal 4 (Illegal instruction) - core dumped
transport_security_state_generator failed with exit code -4
ninja: build stopped: subcommand failed.
*** error code 1
Click to expand...
It's probably crashing when accessing the ID_AA64PFR0_EL1 register. There are 3 files to change:
grep ID_AA64ISAR0_EL1 /usr/ports/www/chromium/files/*
replace id_aa64isar0 = READ_SPECIALREG(ID_AA64ISAR0_EL1); with id_aa64isar0 = 0;
 
CrunchBerry said:
Brian, If you could get Xorg built you made it much further then I could my first stab. but good to here things went reasonably well for you.

Acheron, once again you rock, libiconv built fine with that tip. Wish I found it, maybe have to go back to google over duckduckgo... Now I'll have to read up on poudriere hooks to make sure this stays set for me between ports updates on the off change config.site is changed upstream in the future. or as i look over the available triggers a simple sh script for my poudriere ports update to check for it being set after the update. I'm glad I didn't try to skip this check by finding out a way to force "cross_building=yes" which would make the test basically do the same thing according to the m4 macros. Course that method would likely have broken all sorts of other things in different ways. That was the only thing I could come up with the other night, but it seemed like a bad idea all around.

Here's to giving Xorg another go...
Click to expand...
antoine has committed a workaround (for -current), you can backport the following changes:
github.com

Add usr/bin/wc to HLINK_FILES to workaround casper emulation issues i… · freebsd/poudriere@2772844

…n qemu-user
github.com github.com

[base] Revision 347334

svnweb.freebsd.org svnweb.freebsd.org
 
Thank you Acheron,

I edited those 3 files like you said but now have a new compile error. I think we must be getting closer though:

Code: 
RuntimeError: ../../third_party/node/freebsd/node-freebsd-x64/bin/node ../../third_party/node/node_modules/polymer-css-build/bin/polymer-css-build --polymer-version 2 --no-inline-includes -f /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/bundled/app.vulcanized.html /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/bundled/lazy_load.vulcanized.html -o /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/app.vulcanized.p2.html /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/lazy_load.vulcanized.p2.html failed: Fatal error 'thread 0x4003d85900 exits with resources held!' at line 320 in file /usr/local/poudriere/jails/aarch64/usr/src/lib/libthr/thread/thr_exit.c (errno = 60)

ninja: build stopped: subcommand failed.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/chromium
=>> Cleaning up wrkdir
===>  Cleaning for chromium-73.0.3683.103_2
build of www/chromium | chromium-73.0.3683.103_2 ended at Thu May  9 11:42:57 EDT 2019
build time: 00:33:01
!!! build failure encountered !!!
 
Code: 
Fatal error 'thread 0x4003d85900 exits with resources held!'
It's a qemu bug, unfortunately I have no fix for that...
 
acheron said:
antoine has committed a workaround (for -current), you can backport the following changes:
github.com

Add usr/bin/wc to HLINK_FILES to workaround casper emulation issues i… · freebsd/poudriere@2772844

…n qemu-user
github.com github.com

[base] Revision 347334

svnweb.freebsd.org svnweb.freebsd.org
Click to expand...

I'll keep that one in mind. For now I'm going to hold off on updating my src tree until I confirm all my package building will install on my rpi 3. I hit several other bugs. For instance kept hitting Error 127 on random things, I even had some x11 fonts fail, haven't had font issues in years.... Its kinda like compiling with bad hardware/memory :) I noticed after my first pass qemu-user-static had been bumped so I rebuilt everything in my bhyve for good measure and tried again. The failed ports, like the fonts and python36 finished, but other random errors and hangs happened. I'm thinking the only logical thing to do would be to save work sources between builds and enable core dumping. I'm assuming they'd end up in the work directories anyway. Least then I can maybe try to help debug qemu. Not sure my skills are good enough, but it is certainly time to get comfortable with debuggers, even if my C skills are too lacking too be able to post patches. At least that may help discern what is a ports error, versus a qemu issue.

if this one works next go around I think I can get xorg built, that will give me something to play with. I am definitely finding the longer into the build process something runs, the higher likelyhood of hitting Error 127 which I believe is a missing command from my quick searches that or just a general runaway process being killed issue. Either way random and inconsistent when they appear. Can get around 200 packages built at a clip before enough time has passed to start getting interesting. Obviously without the cores, I can't see whats going on, but I've only recently started coding seriously due to work needs, and never knew what to do with them in the past.

Code: 
=======================<phase: check-sanity   >============================
===>  License BSD3CLAUSE PSFL accepted by the user
===========================================================================
=======================<phase: pkg-depends    >============================
===>   py36-idna-2.8 depends on file: /usr/local/sbin/pkg - not found
===>   Installing existing package /packages/All/pkg-1.10.5_5.txz
*** Error code 127

Stop.
make: stopped in /usr/ports/dns/py-idna
=>> Cleaning up wrkdir
===>  Cleaning for py36-idna-2.8
build of dns/py-idna | py36-idna-2.8 ended at Thu May  9 00:24:43 EDT 2019
build time: 00:00:03
!!! build failure encountered !!!
 
Brian546 said:
Thank you Acheron,

I edited those 3 files like you said but now have a new compile error. I think we must be getting closer though:

Code: 
RuntimeError: ../../third_party/node/freebsd/node-freebsd-x64/bin/node ../../third_party/node/node_modules/polymer-css-build/bin/polymer-css-build --polymer-version 2 --no-inline-includes -f /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/bundled/app.vulcanized.html /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/bundled/lazy_load.vulcanized.html -o /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/app.vulcanized.p2.html /wrkdirs/usr/ports/www/chromium/work/chromium-73.0.3683.103/out/Release/gen/chrome/browser/resources/md_history/lazy_load.vulcanized.p2.html failed: Fatal error 'thread 0x4003d85900 exits with resources held!' at line 320 in file /usr/local/poudriere/jails/aarch64/usr/src/lib/libthr/thread/thr_exit.c (errno = 60)

ninja: build stopped: subcommand failed.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/chromium
=>> Cleaning up wrkdir
===>  Cleaning for chromium-73.0.3683.103_2
build of www/chromium | chromium-73.0.3683.103_2 ended at Thu May  9 11:42:57 EDT 2019
build time: 00:33:01
!!! build failure encountered !!!
Click to expand...

You may want to just give it another go. I've found the random errors come and go, so it is possible it will compile clean on another try. I've definitely been finding that. So far I haven't seen an error that appears to be attributed to a system library error though.
 
Yeah I'm giving it another go. Updated the poudriere ports tree and running a bulk build again. I'll be away on vacation so won't get to see the results until the end of next week. :)
 
You must log in or register to reply here.
Back
Top