poudriere
poudriere copied to clipboard
freebsd
bulk canceled due to expired port
Hi,
With poudriere-3.3.7_1 on 13.1-RELEASE-p2.
If you have an expired port in your list, it just block the all bulk process :
[00:00:39] Gathering ports metadata
[00:00:39] Error: MOVED: www/grafana7 2022-11-07 Has expired: EOLed upstream, unfixed vulnerabilities
[00:00:39] Error: Fatal errors encountered gathering initial ports metadata
[00:00:39] Cleaning up
Is it possible to just have a warning at the beginning and a failed at the end but not blocking the all process?
Thanks!
Replying here and bugzilla.
It occurred to me today that I don't see how this cannot be a hard error. In the "expired" case the port directory is deleted. There is no replacement. What should be done instead? A package that was requested to be built cannot be satisfied. It could build everything else but in the end it will consider it a failure since it could not satisfy the request.
Failing to build the requested port but continuing as long as it has any other entries available to try to build would be one option as that is normally how Poudriere handles port failures. Hard failing can be nice to be aware of the issue so if including a list of ports form a file then that error can be used to help cleanup the list.
An advantage to not proceeding on error is you don't build packages that may lead to requesting that the now missing port be removed; in a bigger update, pkg lists removals near the top of the output (goes away from terminal and possibly buffer depending on amount of packages) and doesn't explain why a pkg is being removed which could be it is moved to another port, renamed, or no new version found that works with dependencies about to be updated and there is no control over which conditions a removal should be considered for. A user needs to edit their list of packages to request be updated (or type a list if originally occurring from pkg upgrade. I'm not aware of a difference to removals presentation between a manually installed pkg and an autoinstalled dependency in this case. Possible unintended pkg removals are avoided in the case of port removal by not being built before being noticed.
An inconsistency this case brings up is: if I list 5 ports to be built and 1 doesn't exist then we have 0 ports built while if they all exist but that same one port cannot be built for a different reason then I have 4 ports built with a build failure logged for the one port and a new set of packages for the other 4. The question is should we fail a whole Poudriere run over an unbuildable port when there is other valid listed work to do and Poudriere has an understanding of marking a port as failed (I'd debate 'skipped' instead would be wrong). Moving the build failure from what is currently done to a hard abort of the entire run would not be advised, even if it matches my portmaster experiences, as the package build clusters normally do not succeed on all ports in the tree.
… should we fail a whole Poudriere run over an unbuildable port when there is other valid listed work to do …
Yes, I think so.
If there's work to do, specify it in a way that is valid:
- ask poudriere to build what's truly required (name the required non-deleted port(s)).
… if I list 5 ports to be built and 1 doesn't exist …
One or more of the four might take days to build.
The sooner things stop, the sooner a human can decide whether building any of the four will be worthwhile in the absence of the deleted port.
It doesn't need to stop for a human to decide if it is still worthwhile to keep the remaining tasks running as long as it can already be logged as a failed request. Logs can be viewed directly, through the web interface if set up, on the terminal if it was manually launched from one, and poudriere build can inform of failures. If it is determined that humans need an 'abort on failure' mode as the only adequate way failures can be dealt with, then it needs to be made available for all failures instead of just "doesn't exist" failures. It could be an option to abort on any failure, or proceed but don't finalize the packages into the currently used repository. Ports successfully built that don't impact the dependency tree of a failed port would be fine to use as is, so leaving them out of a 'creating package repository' would be unnecessary too. Poudriere only seems to watch over ports tree changes among dependencies of a collection of packages properly when you give it the complete list of packages so it should be updated to be watching over all previously created packages to alert that they need to be rebuilt if trying to avoid ports not being listed for rebuild leading to package removal after a ports tree update.
Moved may not be relevant to how the package building machines are used but they otherwise obviously need to not have 'abort on failure' set as there is not enough port maintainers, committers, and focus built around having a ports tree that consists of a strict guideline of 'no port exists but cannot be built'. Getting to such a ports tree state would require a mix of more people working on it, fewer ports, and fewer updates to the remaining ports. Without achieving a state of a fully buildable tree, 'abort on failure' means official package builds would be no more.
I don't recall if Poudriere currently alerts about a full list of moved packages being the reason for abort instead of just the first and then stopping but think I recall it stops before ports with BROKEN defined are populated into the 'ignored ports' list. Each Poudriere run takes time and it doesn't pick up where it left off when it aborts; parts of the build environment get set up again, MOVED file gets checked, ports checks to see if they have an update or their dependencies have an update, etc. get repeated on the next run which repeats the time taken to reach that point. If preemptively aborting on any known error then we need to make sure all errors make it into that list, and those scans need to happen as soon as possible. This still wouldn't address build failures occurring, and they are just as important. The viability of a build with the loss of a related package in the next run is no different for a port not building because a typo was given to Poudriere, its missing from the tree, port ignored because it is now marked as broken, or a port had a build failure as the run progresses.
The result of pkg upgrade being ran on any of those should be the same; once a dependency is updated, a previously installed pkg of a port that now fails will be uninstalled before the dependency can be updated. Unfortunately I haven't found a way to tell pkg to only go about upgrades when it won't remove or break what I already have other than manually listing what to upgrade package by package. Running pkg lock obs-studio-27.2.4;pkg upgrade lists that it will upgrade 8 or so dependencies where attempting to upgrade them (even any one of them) without the lock in place leads to pkg trying to remove obs-studio so it seems like the lock is excluding the package form dependency checks instead of blocking dependency updates that would interfere with it. If it is smart enough to know that the updates are actually compatible, then it should be willing to leave obs-studio too.
I also have a problem with expired port .
I tried merging samba412 with Latest ports tree by using overlays (-O) and get failure.
There is a "custports" portstree which really is just a directory containing net/samba412 port. Then:
# poudriere -v bulk -j 12S -p LATEST -O custports net/samba412 [00:00:01] Creating the reference jail... done [00:00:01] Mounting system devices for 12S-LATEST [00:00:02] Warning: Using packages from previously failed, or uncommitted, build: /usr/local/poudriere/data/packages/12S-LATEST/.building [00:00:02] Mounting ports from: /usr/local/poudriere/ports/LATEST [00:00:02] Mounting ports overlay from: /usr/local/custports [00:00:02] Mounting packages from: /usr/local/poudriere/data/packages/12S-LATEST [00:00:02] Mounting distfiles from: /var/distfiles [00:00:02] Copying /var/db/ports from: /usr/local/etc/poudriere.d/LATEST-options /etc/resolv.conf -> /usr/local/poudriere/data/.m/12S-LATEST/ref/etc/resolv.conf [00:00:02] Starting jail 12S-LATEST [00:00:02] Will build as nobody:nobody (65534:65534) [00:00:02] Logs: /usr/local/poudriere/data/logs/bulk/12S-LATEST/2023-04-05_12h16m30s [00:00:02] Loading MOVED for /usr/local/poudriere/data/.m/12S-LATEST/ref/usr/ports [00:00:03] Ports supports: FLAVORS SELECTED_OPTIONS [00:00:03] Inspecting ports tree for modifications to git checkout... no [00:00:23] Ports top-level git hash: 73ed57c66 [00:00:23] Gathering ports metadata [00:00:23] Error: MOVED: net/samba412 EXPIRED 2022-12-18 Has expired: Reached its EoL on September 20, 2021 [00:00:23] Error: Fatal errors encountered gathering initial ports metadata [12S-LATEST] [2023-04-05_12h16m30s] [crashed:] Queued: 0 Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 Time: 00:00:20 [00:00:23] Logs: /usr/local/poudriere/data/logs/bulk/12S-LATEST/2023-04-05_12h16m30s [00:00:23] Cleaning up [00:00:23] Unmounting file systems Exiting with status 1
There is an expectation that "custports" must overlay LATEST ports tree and so there is no problem with net/samba412. But here it is.
I think there is some checks during "bulk" command which ignores overlay presence. Am I doing something wrong or is it a real issue?
If the overlayed ports tree doesn't also have a MOVED file to replace the original then an error based on its contents should still occur; the replacement needs to no longer have the removal line in it. I'm not sure if there is a line to override a previous removal or if the older removal line gets deleted or commented out in that case. A properly created ports tree also has entries like in the Makefile of the category which lists each ports' directories but not sure when that impacts tools like poudriere.
Thank you! I didn't mention that there is a MOVED file.
If I delete MOVED file will poudriere go wrong?