| Summary: | catalyst-3.0.20: Catalyst fails to unpack portage tree if snap_cache directory does not first exist | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Joshua Kinard <kumba> |
| Component: | Catalyst | Assignee: | Gentoo Catalyst Developers <catalyst> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | mips, releng |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | MIPS | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
catalyst-3.0.20 output log showing failure
stage1 spec file for o32_mips2 |
||
Created attachment 729792 [details]
stage1 spec file for o32_mips2
Attaching my spec file that triggers the bug, in case any of the value help ascertain the core issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ed2c497ad2dd13997997b85c96e52ffd0673fbbd commit ed2c497ad2dd13997997b85c96e52ffd0673fbbd Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2022-01-30 21:03:17 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2022-01-30 21:07:24 +0000 dev-util/catalyst: Version bump to 3.0.21 Closes: https://bugs.gentoo.org/806229 Signed-off-by: Matt Turner <mattst88@gentoo.org> dev-util/catalyst/Manifest | 1 + dev-util/catalyst/catalyst-3.0.21.ebuild | 73 ++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+) |
Created attachment 729780 [details] catalyst-3.0.20 output log showing failure It looks like something in catalyst-3.0.20 is failing to create the target subdirectory under 'snap_cache' before attempting to untar the portage snapshot. E.g., given the following conditions: - My portage snapshot uses a YYYYMMDD datestamp - The catalyst root is /nas/catalyst - "snapcache" is in the catalyst options - snap_cache/ is empty Then during the unpack phase, tar attempts to access /nas/catalyst/snap_cache/YYYYMMDD, and fails because the 'YYYYMMDD' directory does not exist. If I manually create this directory first, then it proceeds to unpack normally. I diffed back several versions, and the only standout was the removal of the locking code around the unpacking code between 3.0.18 and 3.0.19. However, I don't know if snakeoil's locking code may have done something helpful like create a missing directory before locking it if it didn't yet exist, or if something somewhere else in catalyst is failing to do a 'mkdir' first to create the snap_cache/YYYYMMDD folder. I've attached the output log of a failed run. There are also two syntax warnings worth looking at that popup unrelated to this issue when you force Python to recompile catalyst's modules, which I discovered when editing stagebase.py to toss in some debugging code: /usr/lib/python3.9/site-packages/catalyst/base/stagebase.py:484: SyntaxWarning: "is" with a literal. Did you mean "=="? self.settings["source_matching"] is "strict" /usr/lib/python3.9/site-packages/catalyst/base/stagebase.py:1124: SyntaxWarning: "is not" with a literal. Did you mean "!="? if flags not in self.settings or (flags is not "COMMON_FLAGS" and