File /usr/lib/portage/python3.6/doins.py, line 195, in run sstat = os.stat(source) FileNotFoundError: [Errno 2] No such file or directory: b*.ttf * ERROR: media-fonts/jetbrains-mono-1.0.3::gentoo failed (install phase): * doins failed * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma_systemd-20200318-121516 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.3.0 * clang version 10.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.0 Available Python interpreters, in order of preference: [1] python3.8 [2] python3.6 [3] python3.7 (fallback) [4] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-bin-1.41.1 [2] rust-1.41.1 * The following VMs are available for generation-2: *) IcedTea JDK 3.14.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.0.2 timestamp of HEAD at this tinderbox image: /var/db/repos/gentoo Sat 21 Mar 2020 07:08:40 AM UTC emerge -qpvO media-fonts/jetbrains-mono [ebuild N ] media-fonts/jetbrains-mono-1.0.3 USE="X"
Created attachment 623760 [details] emerge-info.txt
Created attachment 623762 [details] emerge-history.txt
Created attachment 623764 [details] environment
Created attachment 623766 [details] etc.portage.tbz2
Created attachment 623768 [details] media-fonts:jetbrains-mono-1.0.3:20200321-090851.log
Created attachment 623770 [details] temp.tbz2
I cannot reproduce this issue locally. Also none of the log files gave me any insight. Can you give a tree view of the build directory just before the error occurs? Otherwise I feel there is not much I can do here.
I'm sure this is somehow related (again) to fonts.eclass update. https://gitweb.gentoo.org/repo/gentoo.git/log/eclass/font.eclass but don't currently have time to dig deeper.
Hi Jan, the issue is that font_src_install calls "doins *.tff" from directory "${S}" rather than "${S}"/ttf. To fix that, the ebuild needs a line: FONT_S="ttf" . PS: Top reproduce, local "ebuild jetbrains-mono-1.0.3.ebuild manifest clean install" took me straight to the error.
Hi Sebastian, that line already exists in the ebuild (line 19). So unfortunately this does not help in me regard of this bug. Also "ebuild jetbrains-mono-1.0.3.ebuild manifest clean install" does not reproduce the error on my machine.
Okay, I now found the source of confusion. The line in question was added in commit https://github.com/gentoo/gentoo/commit/f69811f5167ac9df8c20abdfb86a94ee030b9eca to the 1.0.0 ebuild. Two days later I bump the version to 1.0.3 coping over the ebuild with the line. For reasons unknown to me (and also entirely unknown) the original commit was reverted in commit https://github.com/gentoo/gentoo/commit/a4234be897ea2aa03fe66bb8c05eb9b927bc22ed, but this time also removing that line from the 1.0.3 ebuild. I still have the version with that line in my local overlay (which I use to test ebuild before creating PRs). That is why I could not reproduce this issue. This still leads to the question, why was the commit reverted and why did the revert also change a file, which was not part of the original commit?
Interesting! I'm adding ulm to CC now... > This still leads to the question, why was the commit reverted and why did > the revert also change a file, which was not part of the original commit? From a closer look at the ebuilds, the two commits by ulm and the file structure extracted from the files, I believe we need: - no FONT_S line for jetbrains-mono-1.0.0.ebuild (because .tff files reside in ${S}; status quo) - FONT_S="ttf" for jetbrains-mono-1.0.3.ebuild (because .tff files reside in ${S}/ttf; yet to do) I'm happy to make that happy if you agree it's the right fix.
The reverts in media-fonts were following the font.eclass update for bug 613108. There were some conflicts, but I don't remember if there was one for this package. (Also I thought I had tested everything, but maybe I did only 1.0.0? Sorry for that.) Anyway, I think that the ebuild for 1.0.3 should simply do S="${WORKDIR}/JetBrainsMono-${PV}/ttf", because it doesn't need anything from outside this directory.
(In reply to Ulrich Müller from comment #13) > Anyway, I think that the ebuild for 1.0.3 should simply do > S="${WORKDIR}/JetBrainsMono-${PV}/ttf", because it doesn't need anything > from outside this directory. I get the idea about adjusting ${S} and it should work. It seems a bit more complex though and I would argue that FONT_S="ttf" is a better fit, semantically: FONT_S seems made for this very case. I'm happy either way. How should we go forward?
It will work either way. I'd prefer adjusting S, because all relevant files are in the ttf subdir.
I am also fine with both ways. For the 1.0.4 ebuild (see the linked bug) I have just applied ulm's suggestion and set S="${WORKDIR}/JetBrainsMono-${PV}/ttf". I suggest to go for the same for the 1.0.3 ebuild. Would either of you do that directly on the tree? Then we do not have to wait for a PR to get reviewed and merged.
Please make a PR because you tested it works - I'll commit immediately today.
Alright, I'll take care of applying the ${S} approach now, give me a second.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=132301c8b48fa0febc17563697215fdfd2c88e63 commit 132301c8b48fa0febc17563697215fdfd2c88e63 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2020-03-25 14:06:45 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2020-03-25 14:07:18 +0000 media-fonts/jetbrains-mono: Fix 1.0.3 compilation .. by syncing ${S} with 1.0.4 ebuild. Closes: https://bugs.gentoo.org/713774 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-2.3.92, Repoman-2.3.20 media-fonts/jetbrains-mono/jetbrains-mono-1.0.3.ebuild | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Thank you, and sorry again for the breakage.