www/ungoogled-chromium port missing from FreeBSD:14:amd64

S

snakedoctr

Hi all,
Anyone know why www/ungoogled-chromium is missing from FreeBSD:14:amd64? The latest update I received was to v119.0.6045.199, which was released on 2023/11/29. It appears FreeBSD:13:amd64 and i386 both have the latest version, but all platforms under FreeBSD:14 are missing it. Anyone know what's wrong with FreeBSD 14 builds for this?

Thanks!
 
For me Chromium & Ungoogled-Chromium did not build as port under poudriere.
Probably some bug. Will get fixed after some time.
 
Alain De Vos said:
Probably some bug. Will get fixed after some time.
Click to expand...
I highly doubt that.
The problem of runaway build jobs for chromium and related browsers has been ignored by upstream for years now. Seems like for them there is no problem if it is ignored long enough...
 
All chromium ports (iridium, ungoogled-chromium and chromium) are consistently hitting build time-out since January at least. There's no real issues with these builds, it just that they take too long to build. That's 3 x 48 hours of build time going to waste every single time. I'm not sure if anyone is working on a solution. I'm using version 121 that took 3 days to build on my laptop. I'm not planning to update this version anytime soon!
 
cracauer@ said:
What kind of parallelism do these compiles run at, anyway?
Click to expand...
the last times I tried to build ungoogled-chromium there always was a single thread idling around for most of the time, waking up every few seconds and going back to doing nothing. So yes, there *is* an issue and last time I checked, there have been reports about this for a long time, but most of them stalled or simply closed but unresolved, so I doubt there is any interest in fixing this from upstream...
 
I just tried to compile "chromium-browser" on gentoo-linux. But it's taking ages. I stopped it. Software should be compile-able in acceptable time or be dropped. Which i did.
 
  • Like
Reactions: mro
I'm building that sucker right now. Parallelism is <ncpu> in the port without you having to give a -j (in fact giving -j <n> is broken).

I see <ncpu> C++ processes and also lots of C++ processes with 0% CPU. This does no harm as the CPUs are all 100% busy, but it is odd I'd say.
 
Time for www/chromium was
1:33:07 5587.67 real 330467.63 user 13465.54 sys 6155% CPU 24302/2016978038 faults

Not too bad. I did not observe any CPU idling. 15-current.
 
No exceptional behaviour with chromium observed here:
Code: 
          compute    vcore      wallclck       parall                 tag
chromium:
        107:37:27       11      10:14:55         1.05   240106234745.disp
        121:43:24       10      12:32:22         1.03   240225220936.disp
        136:26:49       10      14:50:15         1.09   240301145351.disp
        117:13:00       15       8:08:36         1.04   240124150509.disp
        101:04:12       11      10:23:21         1.13   231002230759.disp
         87:56:51       10       9:36:20         1.09   231128133820.disp
         89:12:32       16       5:48:27         1.04   231016062014.disp
        106:15:37       10      11:56:37         1.12   231021161212.disp

Looks like it's steadily growing, at a quite impressive rate.
 
(sorry for dumping screenshots)

I've given www/ungoogled-chromium another try and started a build job yesterday:
1710313125310.png


system load (blue lines) as usual has been negligible from the very beginning of the build after unpacking and configuring:

1710313252827.png


the big spike were the dependencies (especially llvm17) being built and ungoogled-chromium being unpacked and configured. After that theres (as always) only a single clang thread surfacing for 1-2seconds with ~80-100% on one CPU, then several seconds absolute silence.
I already know that this build will also never finish because it never had in forever. These are only some of the build attempts:
2024-01-30:
1710280824980.png


2023-11-13:
1710280853093.png


2023-08-10:
1710280909270.png


At least since July 2023 (I don't have any poudriere logs older than that, but this issue has been present *much* longer) this port never finished to build on that 13.2-RELEASE buildhost which is a Dual Xeon E5-2660 system with 256GB RAM and poudriere using a dedicated ZFS pool on 2 mirrored NVMe SSDs.
Same story on my buildhost at home with same CPUs and 128GB RAM; also running 13.2-RELEASE since ~November 2023; before that it ran and built for 12.4-RELEASE (and 12.3, but can't remember if I already tried to build ungoogled-chromium back then).
*Also* the same story in a 14.0-RELEASE bhyve VM where I build packages for my laptop - I've only tried to build that thing once or twice there and killed the build after a few hours with the same catatonic behavior because I want to use that VM to *actually* build packages...
This port was always the very last thing holding up the bulk job from finishing, so it had *all* of the system available to build, but never actually uses any meaningful CPU time, let alone more than a single core.

Options for the port were either default or trimmed down (e.g. CUPS and/or KERBEROS off). LTO was never enabled.

I can't find the github bug report from around a year ago (IIRC; it could as well have been a bugtracker PR or mailing list conversation) where I also confirmed/reported those build timeouts. Back then a developer played the reports down and stated in all seriousness that "50-60h is considered a normal build time" (excluding dependencies!!). This was the point for me where I left that conversation...


Alain De Vos said:
Software should be compile-able in acceptable time or be dropped. Which i did.
Click to expand...
Maybe a PR with the proposal to remove the port entirely might put enough pressure on upstream to finally fix their build times?
At worst we will free the build cluster from this thing that is holding up the queue for *2 full days* on each run...
 
Since you have 8 builder available, I assume that you didn't change any default of poudriere.
By default poudriere will not allow each individual ports to have more than one process.
The solution is to have
Code: 
ALLOW_MAKE_JOBS=yes
PARALLEL_JOBS=1
You could also use
Code: 
ALLOW_MAKE_JOBS_PACKAGES="ungoogled-chromium"
So don't blame upstream when the issue arise from not configuring poudriere correctly for this use case.
 
monwarez said:
Since you have 8 builder available, I assume that you didn't change any default of poudriere.
Click to expand...
There were only 16 ports to build for that bulk job, so poudriere only created those 8 builders. Usually there are 56 available.

monwarez said:
By default poudriere will not allow each individual ports to have more than one process.
Click to expand...
its *one process per CPU*:
Code: 
# By default MAKE_JOBS is disabled to allow only one process per cpu
# Use the following to allow it anyway
# ALLOW_MAKE_JOBS=yes

regardless of that; chromium/ungoogled-chromium is also in the 'ALLOW_MAKE_JOBS_PACKAGES' list along with llvm, gcc, rust, node, firefox and some other notoriously bloated ports that all build in reasonable time.

Code: 
# grep -ve '^#.*' -e '^$' /usr/local/etc/poudriere.conf
ZPOOL=nvme_pool
FREEBSD_HOST=https://download.freebsd.org
RESOLV_CONF=/etc/resolv.conf
BASEFS=/usr/local/poudriere
USE_PORTLINT=no
USE_TMPFS=yes
TMPFS_BLACKLIST="rust"
TMPFS_BLACKLIST_TMPDIR=${BASEFS}/data/cache/tmp
DISTFILES_CACHE=/usr/local/poudriere/ports/distfiles
CHECK_CHANGED_OPTIONS=verbose
PKG_REPO_SIGNING_KEY=/usr/local/etc/poudriere.d/keys/pkg.mydomain.tld.key
CCACHE_DIR=/usr/local/poudriere/data/cache/ccache
SAVE_WRKDIR=yes
NO_FORCE_PACKAGE=yes
ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* rust* llvm* gcc* node* cmake ungoogled-chromium qt5-* qt6-* firefox* "
KEEP_OLD_PACKAGES=yes
BUILDER_HOSTNAME=pkg.mydomain.tld
PRIORITY_BOOST="pypy openoffice* node rust* py* cmake llvm* clang* gcc*"
URL_BASE=https://pkg.mydomain.tld/
HTML_TYPE="hosted"
HTML_TRACK_REMAINING=yes

even libreoffice which is *not* in the ALLOW_MAKE_JOBS_PACKAGES list builds in a normal timeframe - simply because it actually *does* build. with several processes. on several CPUs. constantly *working* on those CPUs. not a single thread limping around and waiting for god-knows-what...
 
It is usually not difficult to look into a port and see what it does to build or does not. (It is a lot simpler than to look into the kernel what it does)
It's certainly unpleasant, as this thing is rather big. But then, I don't think...

sko said:
god-knows-what...
Click to expand...

... God is really pleased either by getting this job delegated. *eg*

libreoffice, as we know, does also sometimes hang. But only sometimes, so there the workaround is to run it again. That one, as far as I figured, is a java problem that apparently happens only on FreeBSD. But nobody is interested in fixing it.
gcc12 also has an issue - when building with more than 18 vCore the build time explodes. Maintainer says this is works-as-designed.

I remember the old times when we did actual engineering: you came to some insight about a problem, you turned to somebody else and they would supplement it from their knowledge, and very quickly the issue was fixed.
Nowadays this has become a ship of fools. (And everybody is welcome to grab their own nose.)
 
Have you tried with
Code: 
ALLOW_MAKE_JOBS=yes
PARALLEL_JOBS=1
On my machine it does use all the 12 available threads.
So if you have like 56 available, then it would take you about 1hour to 1h30 .
sko said:
its *one process per CPU*:
Click to expand...
The documentation says so, but looking at the source code it seems to put DISABLE_MAKE_JOBS=poudriere in make.conf
Which result in the port tree: MAKE_JOBS_NUMBER=1
Code: 
case "${ALLOW_MAKE_JOBS-}" in
		yes) ;;
		*)
			echo "DISABLE_MAKE_JOBS=poudriere" \
			    >> "${MASTERMNT:?}/etc/make.conf"
			;;
		esac

Normally it should be removed here
Code: 
	for jpkg_glob in ${ALLOW_MAKE_JOBS_PACKAGES}; do
		# shellcheck disable=SC2254
		case "${pkgbase}" in
		${jpkg_glob})
			job_msg_verbose "Allowing MAKE_JOBS for ${COLOR_PORT}${port}${FLAVOR:+@${FLAVOR}} | ${pkgname}${COLOR_RESET}"
			sed -i '' '/DISABLE_MAKE_JOBS=poudriere/d' \
			    "${mnt:?}/etc/make.conf"
			break
			;;
		esac
	done
 
PMc said:
Might be too many available cores? ;)
Click to expand...

Well, the claim was that the build fails to complete because it has lots of idle time. I did not observe that.

Plus, my time multiplied by a "normal" core count is still not 48 hours.
 
You must log in or register to reply here.
Back
Top