cracauer@
Developer
If extracting takes more than an hour your disk is very slow.
For a long time I used an old Core i5-3470 with 16GB memory (and 16G of swap). Took forever to build packages, but it worked. You'll want to set
MUTUALLY_EXCLUSIVE_BUILD_PACKAGES="llvm* rust* gcc*" in poudriere.conf though. Or else you will eventually end up building rust, llvm and gcc at the same time, and this will certainly burn down the entire host.USE_TMPFS=all, PARALLEL_JOBS=6 and ALLOW_MAKE_JOBS=yes. This thing builds packages lightning fast compared to that old i5.For those memory pressures are concern and swap is small and/or slow, webkit*, *chromium*, iridium*, qt*-webengine* would be wanted to be in the list. These are quite heavy-loaded, too.
I found the wrkdir which is apparently recreated from scratch for each poudriere build, so in my specific case the presence of pre-existing wrkdir files shouldnt be the issue.
[root@homebsd /usr/local/poudriere/data/.m/13amd64-local/01/wrkdirs/usr/ports/www/chromium/work]# ls
.configure_done.chromium._usr_local .license-catalog.mk .license_done.chromium._usr_local BSD3CLAUSE
chromium-135.0.7049.114
.extract_done.chromium._usr_local .license-report .patch_done.chromium._usr_local chrome
chromium-browser.desktop
[root@homebsd /usr/local/poudriere/data/.m/13amd64-local/01/wrkdirs/usr/ports/www/chromium/work]#
[root@homebsd /usr/local/poudriere/data/.m/13amd64-local/01/wrkdirs/usr/ports/www/chromium/work]#
[root@homebsd /usr/local/poudriere/data/.m/13amd64-local/01/wrkdirs/usr/ports/www/chromium/work]# ls
ls: .: Not a directory
[root@homebsd /usr/local/poudriere/data/.m/13amd64-local/01/wrkdirs/usr/ports/www/chromium/work]#During these last build attempts in which I only specified USE_TMPFS=data I no longer experienced swap issues. Thank you for insisting on reading the logs by scrolling backwards to find the real error. I actually keep seeing the following error which I think might be related to this recently discovered bug.
gen/third_party/blink/renderer/core/css/css_property_names.cc:154:7: error: fallthrough annotation does not directly precede switch label
154 | [[fallthrough]];
| ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]I think it was only due to the fact that I had limited ARC to 4g. By restoring the default setting I get past the extraction point without issues.
Thank you very much for sharing this information. It's useful to know about the extra options but even more useful to hear about your personal experience and way of building software.
Thanks for the link to the script, it seems like it could be very useful.
I've created (and made it faster thanks to DutchDaemon) this script because with
-a option for bulk builds sometimes caused, for example, www/chromiun to be built in the middle (near the last, though) and the finish time of whole builds is delayed 12+ hours even though there was some security fixes of fundamental ports that I wanted to update ASAP.
WANTSPACE and WANTMEM in it.
WANTSPACE=35GB of SSD storageWANTMEM=8GB of RAMYeah, if we disregard the build time.
So, who's gonna file the PR and get the makefile edited to reflect correct values? Those values were for a non-debug build. The Makefile also included different values for a build with debugging symbols compiled in - like 240 GB of SSD storage, iirc.
git pull sorted that. USE_TMPFS=yes and when I reached the final chromium port then used USE_TMPFS=data. I still don't know exactly why I couldn't get past the extract part for chromium just before the actual build. This wasn't an issue I had encountered when I started this thread but occured after many build attempts. Maybe freeing some space on the ZFS pool helped? I honestly don't know). git pull and rebuild like in my case? (I had to issue git pull twice, not only for chromium but also to fix an issue with the libxslt port).I actually don't do that... A few years ago, I was working on a Poudriere-based project that includes this step, but had to set that project aside, as other things IRL demanded my attention. What I end up doing is basically grabbing a fresh copy of ports whenever I do a fresh install of FreeBSD. I compile Firefox on the spot, and then wait until it says no more, then I rinse and repeat.
Well, most of Poudriere-specific options are definitely found in the manpages. Poudriere does a pretty good job of respecting the Makefile flags that are set using the Ports system. Sometimes, it's a matter of figuring out if an option was set by Poudriere or make.conf or a jail or by some other component.
I have a intel 10th gen i5-10500T. I tried to find relevant information about 'port compilation' problems, I couldn't find any. Could you elaborate on that?
Don't you risk having many vulnerabilities like that? I have recently compiled chromium and firefox and
pkg audit -F already shows vulnerabilities for both.Thanks for that. I probably just need time then to understand how those components work together.
pkg check -nd I see the following:aaron@homebsd ~ % pkg check -nd
Checking all packages: 100%
cinnamon is missing a required shared library: libmuffin-clutter-0.so.0
cinnamon is missing a required shared library: libmuffin-cogl-0.so.0
cinnamon is missing a required shared library: libmuffin-cogl-pango-0.so.0
cinnamon is missing a required shared library: libmuffin-cogl-path-0.so.0
aaron@homebsd ~ % pkg check -nd regarding missing libraries since I installed all my packages from the poudriere repository which I imagine is some sort of an "all consistent whole". pkg delete '*', checked to make sure there were no remaining packages and then issued pkg install `pkg search -g \* | awk '{print $1}'` to install all the packages contained in the new poudriere repository).And still if and when possible could someone please let me know if this is the correct way to build packages beforehand for another major release of FreeBSD?
Well, for vulnerabilities, I have to ask myself what it means in practice for me. Exactly what needs to happen for that particular issue to actually mess up my FreeBSD machine or my offline functioning? I usually try to avoid running stuff as root if I can help it. And thing is, if I were curious enough about that, I'd try to do penetration testing on my own network just to see how much effort it would take to see the veracity of that particular CVE, and how applicable it would be in my particular case.
That is reasonable. The only issue is that specific software CVEs
pkg audit reports are too difficult for me to really understand. So I prefer just updating the affected software. In contrast, I find FreeBSD's Security Advisories awesome because they summarize in a very exemplificative way the "Problem" and "Impact" of the vulnerabilities, which really helps me make an informed decision. But when it comes to reading the Chromium or Firefox vulnerabilities, I get quite lost.I only just realized that poudriere had correctly built libmuffin, so I'm guessing that as you mentioned what I see isn't a real issue. It definitely makes me want to start reading Porter's Handbook to start to understand how dependencies are handled (
LIB_DEPENDS, RUN_DEPENDSetc.).