Summary: | emerge produces misleading output suggesting it's compiling multiple packages at a time when it's not. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | dE <de.techno> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | de.techno, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=663324 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
dE
2024-02-10 11:16:53 UTC
It's supposed to compile them in parallel if you use emerge --jobs, but delay the install until no builds are running due to the new default FEATURES=merge-wait setting related to bug 663324. If you set FEATURES="-merge-wait" in make.conf then you'll get back the previous behavior. (In reply to dE from comment #0) > This was working as expected since around Jan 8th or 9th till 9th Feb, but > when I upgraded on 9th Feb, it started to produce output as -- > >>> Emerging (1 of 6) app-cdr/xfburn-0.7.0::gentoo > >>> Emerging (2 of 6) media-sound/audacity-3.3.3::gentoo > >>> Emerging (3 of 6) app-emulation/virtualbox-7.0.12-r2::gentoo > >>> Emerging (4 of 6) media-video/parole-4.18.1::gentoo > >>> Emerging (5 of 6) net-im/telegram-desktop-4.13.1::gentoo > >>> Failed to emerge net-im/telegram-desktop-4.13.1, Log file: > >>> '/tmp/portage/net-im/telegram-desktop-4.13.1/temp/build.log' > >>> Jobs: 0 of 6 complete, 1 running, 1 failed Load avg: 8.89, 7.43, 4.53 > > Note there is no 'installing' or 'completed' phase as in the previous commit > of portage -- it does come but at the wrong time. That's the FEATURES=merge-wait change. > In the above e.g only 1 > ebuild is being compiled (check the jobs:) and it looks like it's compiling > 5. That's odd because I'd expect them all to be in the running state rather than just "1 running" as shown there. I tested locally with 3 packages just now and FEATURES=merge-wait, and all 3 packages immediately entered the running state: >>> Jobs: 0 of 3 complete, 3 running Load avg: 0.78, 0.97, 1.39 FEATURES=merge-wait is only supposed to affect what happens when a build completes, since it's implemented where PackageMerge instances are created and handled in a _build_exit callback after a build completes: https://gitweb.gentoo.org/proj/portage.git/commit/?id=825db01b91a37dcd9890ee5bf9f462ea524ac5cc With FEATURE=merge-wait, if some package has finish compiling while others are With -merge-wait things start working fine. (In reply to dE from comment #2) > With FEATURE=merge-wait, if some package has finish compiling while others > are With -merge-wait things start working fine. This typically works pretty well, but be warned that there are certainly some rare cases like bug 663324 where you could experience "random" build failures, so that is why it is no longer the default behavior. (In reply to Zac Medico from comment #1) > (In reply to dE from comment #0) > > In the above e.g only 1 > > ebuild is being compiled (check the jobs:) and it looks like it's compiling > > 5. > > That's odd because I'd expect them all to be in the running state rather > than just "1 running" as shown there. I tested locally with 3 packages just > now and FEATURES=merge-wait, and all 3 packages immediately entered the > running state: > > >>> Jobs: 0 of 3 complete, 3 running Load avg: 0.78, 0.97, 1.39 We still have this oddity to reconcile. I assume that you did not observe an issue with the number of running jobs with FEATURES="-merge-wait", but such an issue also should not have been triggered by merge-wait for any known reason. Sorry, the last message was half baked. No, I did not face the issue with FEATURES="-merge-wait" and it did happen with merge-wait. |