Following the dev manual to set up a Chroot: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Reading_news_items I perform an emerge-webrsync the emerge-webrsync ends with: * IMPORTANT: 11 news items need reading for repository 'gentoo'. * Use eselect news read to view new items However, immediately afterwards, eselect news reports nothing: # eselect news list News items: (none found) This behaviour happened identically in 2-chroots. Chroot-1: stage3-amd64-nomultilib-20161124.tar.bz2 Chroot-2: stage3-i686-20161129.tar.bz2 And the snapshot fetched in both cases was: - portage-20161202.tar.xz Using those images versions of eselect/portage/everything ( no upgrades have been performed ): =app-admin/eselect-1.4.5 =sys-apps/portage-2.3.0
In fact, subsequent emerges still show this annoying notifaction, but eselect still can't see it :/
Ok, the cause for the problem appears to be as follows: Outside the chroots I'm building, I have paludis installed and set as "the package manager", and it turns up in PACKAGE_MANAGER=paludis chrooting doesn't clear this env field, so it is still ambient in the chroot /etc/profile in the chroot does not change this field. But lo, paludis is *NOT* installed in the chroot. And eselect appears to run down that dead end as a result: + local item stat repo dir header line title posted i=1 + local cols=277 'ifs_save= ' + local -a repos dirs ++ find_items unread read +++ get_repositories +++ case $(package_manager) in ++++ package_manager ++++ local pm ++++ case ${PACKAGE_MANAGER} in ++++ pm=paludis ++++ echo paludis +++ run_paludis print-repositories +++ cave print-repositories ++ local stat repos= repo file item ++ sort -t / -k 3 ++ for stat in '"$@"' ++ for stat in '"$@"' + set -- + write_list_start 'News items:' ^ it basically finds no repositories, and so cant' print news from said repositories. calling `unset PACKAGE_MANAGER` then makes eselect news actually work again :)
So, INVALID then?
(In reply to Mike Gilbert from comment #3) > So, INVALID then? No. More: 1. Should not silently continue when calling paludis fails ( should bail instead ) 2. PACKAGE_MANAGER crossing the chroot boundary should be considered something that needs fixing in the default /etc/profile (somehow)
(In reply to Kent Fredric (IRC: kent\n) from comment #2) > +++ get_repositories > +++ case $(package_manager) in > ++++ package_manager > ++++ local pm > ++++ case ${PACKAGE_MANAGER} in > ++++ pm=paludis > ++++ echo paludis > +++ run_paludis print-repositories > +++ cave print-repositories Right, either get_repositories() or its caller should die when there is an error, or when the list of repositories is empty.
Created attachment 455040 [details, diff] Check return status of package manager calls in news module. Can you test if attached patch fixes the problem for you?
# eselect news list !!! Error: Cannot get list of repositories Call stack: * find_items (news.eselect:18) * do_list (news.eselect:178) * check_do (core.bash:24) * do_action (core.bash:105) * main (eselect:179) News items: (none found) exiting ^ I'd hope for something more obvious, given how easy it is to trip this behaviour unintentionally.
Can you please suggest a better error message than "Cannot get list of repositories" if get_repositories() returns with an error?
(In reply to Ulrich Müller from comment #8) > Can you please suggest a better error message than "Cannot get list of > repositories" if get_repositories() returns with an error? Ideally you want get_repositories() to explain *why* it can't get repositories. "Cannot get list of repositories: cave not installed and PACKAGE_MANAGER=paludis" "Cannot get list of repositories: cave print-repositories returned no results" etc.
Well, how would we know that cave is not installed? It may have failed for whatever reason. get_repositories() calls the run_paludis() wrapper which in turn calls the cave command. There we get a non-zero return status which travels back up to find_items. Also note that stderr for cave is redirected to /dev/null because paludis tends to output lots of warnings even if the command succeeds. So the "cave: command not found" message won't be seen. We could do something like this: --- a/libs/package-manager.bash.in +++ b/libs/package-manager.bash.in @@ -36,7 +36,12 @@ # run_paludis PRIVATE # Run CAVE (defaults to "cave"). Redirect stderr run_paludis() { - ${CAVE:-cave} "$@" 2>/dev/null + local ret logfile=$(mktemp "${TMPDIR:-${ROOT}/tmp}/eselect.log.XXXXXX") + ${CAVE:-cave} "$@" 2>"${logfile}" + ret=$? + [[ ${ret} -eq 0 ]] || cat "${logfile}" >&2 + rm -f "${logfile}" + return ${ret} } # arch That is, save the stderr output and display it only if the command failed. But I believe that would be over-engineered. And it may cause other problems, for example mktemp may fail because the user hasn't purged TMPDIR from the environment when entering a chroot. Anyway, I have updated the error messages to say "Package manager ..." so that there is at least a hint where to look for the problem: - repos=$(get_repositories) || die "Cannot get list of repositories" + repos=$(get_repositories) \ + || die "Package manager cannot get list of repositories" - || die "Cannot get news dir for repo ${repo}" + || die "Package manager cannot get news dir for repo ${repo}"
(In reply to Ulrich Müller from comment #10) > - repos=$(get_repositories) || die "Cannot get list of repositories" > + repos=$(get_repositories) \ > + || die "Package manager cannot get list of repositories" > > - || die "Cannot get news dir for repo ${repo}" > + || die "Package manager cannot get news dir for repo ${repo}" I think you could increase the clarity of why with the phrasing: "Package manager ($(package_manager)) cannot get list of repositories" Then seeing an obviously wrong package manager listed would be a good hint.
(In reply to Kent Fredric (IRC: kent\n) from comment #11) > I think you could increase the clarity of why with the phrasing: > > "Package manager ($(package_manager)) cannot get list of repositories" Yeah, that would require making package_manager() a public function. I'll think about it.
Committed to master: https://gitweb.gentoo.org/proj/eselect.git/commit/?id=24b7b6c3026e62b519922cf81074594fbd573ef8 Waiting for bug 304011 until making a new release.
