After the upgrade to texlive 2024, I receive the following pdflatex error on the following minimal example: $ cat minimalexample.tex \documentclass[tikz]{standalone} \usepackage{circuitikz} \begin{document} \end{document} $ pdflatex minimalexample.tex […] (/usr/share/texmf-dist/tex/generic/circuitikz/pgfcirc.defines.tex ! Package pgfkeys Error: The key '/pgf/arrow keys/fill' requires a value. I am going to ignore this key. See the pgfkeys package documentation for explanation. Type H <return> for immediate help. ... l.415 ...ap[swap,fill]}, ^f/.tip={Jack Tap[fill]}}
workaround: emerge -Ov1e =dev-texlive/texlive-pictures-2023_p69409-r3 I'm not familar with the tikz, to be inverstigated ...
There is a another workaround: \documentclass[tikz]{standalone} \ExplSyntaxOn \cs_undefine:c {pgfk@/pgf/arrow~keys/fill/.@def} \ExplSyntaxOff \tikzset{/pgf/arrow keys/fill} \usepackage{circuitikz} \begin{document} \end{document} I cam to this by the following code in /usr/share/texmf-dist/tex/generic/circuitikz/pgfcirc.defines.tex after line 397: % the new "fill without arg" will be in TikZ 3.1.11. Apply it here if we have an % older version \ctikz@@ifpgfafter 2023-01-16{\relax}{% % thanks @muzimuzhi https://github.com/pgf-tikz/pgf/issues/1348#issuecomment-2229075269 % undo the fill/.value required key \expandafter\let\csname pgfk@/pgf/arrow keys/fill/.@def\endcsname\@undefined Hence, I would regard https://github.com/pgf-tikz/pgf/issues/1348#issuecomment-2229075269 as a relevant source. What is confusing: It fixes something for tikz >=3.1.11, by checking ifpgfafter 2023-01-16. However in my pgf.revision.tex I have pgfversion 3.1.10 and pgfversiondatetime 2024-02-09. This sounds fishy. So as a quick check: If I change the following: %\ctikz@@ifpgfafter 2023-01-16{\relax}{% \ctikz@@ifpgfafter 2025-01-16{\relax}{% in /usr/share/texmf-dist/tex/generic/circuitikz/pgfcirc.defines.tex:397, the counter example also works again. And my actual latex project where I use this package works well, too. My best guess at this point is: ifpgfafter 2023-01-16 wrongly thinks that tikz/pgf 3.1.11 is installed, while it is 3.1.10.
> So as a quick check: If I change the following: > > %\ctikz@@ifpgfafter 2023-01-16{\relax}{% > \ctikz@@ifpgfafter 2025-01-16{\relax}{% > > in /usr/share/texmf-dist/tex/generic/circuitikz/pgfcirc.defines.tex:397, the > counter example also works again. And my actual latex project where I use > this package works well, too. > > > My best guess at this point is: ifpgfafter 2023-01-16 wrongly thinks that > tikz/pgf 3.1.11 is installed, while it is 3.1.10. thanks, issue submitted at https://github.com/circuitikz/circuitikz/issues/843
/usr/share/texmf-site/tex/generic/pgf/pgf.revision.tex if change pgfversiondatetime & pgfrevisiondatetime from 2024-02-09 to 2023-01-15, example works too. I don't how "2024-02-09" is determined, from https://github.com/pgf-tikz/pgf/releases 3.1.10 is released at 2023-01-15? # grep datetime /var/db/repos/gentoo/dev-tex/pgf/pgf-3.1.10.ebuild \gdef\pgfversiondatetime{2024-02-09 00:00:00 +0000} \gdef\pgfrevisiondatetime{2024-02-09 00:00:00 +0000} \xdef\pgfversiondate{\expandafter\pgf@glob@TMPa\pgfversiondatetime\relax} \xdef\pgfrevisiondate{\expandafter\pgf@glob@TMPa\pgfrevisiondatetime\relax}
Ok, but isn't this then a Gentoo bug? If you have a look at the pgf package then pgf.revision.tex is not part of the repo, but it is written by build.lua. The respective date is read from options --revision-date. By the Gentoo ebuild the entire pgf.revision.tex is provided as a plain content. The date 2024-02-09 appears to be wrong by this evidence: - The CHANGELOG.md of pgf says: ## [3.1.10] - 2023-01-13 Henri Menke - This example uses 2023-01-15: https://mirror.kumi.systems/ctan/graphics/pgf/base/tex/generic/pgf.revision.tex, which is the date of the date of the git tag of 3.1.10. This quite clearly hints to a bug in the ebuild file, and 2024-02-09 should be changed to 2023-01-15. In particular, I do not think this is an upstream bug.
> This quite clearly hints to a bug in the ebuild file, and 2024-02-09 should > be changed to 2023-01-15. yes, i think so. But I don't how 2024-02-09 comes, so I'll leave this to gentoo developer. > In particular, I do not think this is an upstream bug. yeah, but since pgf 3.1.11 is not released, the comment might cause some confusion?
The error-prone assumption made in circuitikz is that every release after 2023-01-16 is after version 3.1.10, e.g., 3.1.11. This, I think, should be changed upstream in circuitikz. And still Gentoo should provide a pgf.revision.tex containing dates conforming with other distributions. My 2 cents.
Looking at upstream's build.lua, revisiondate is the date of the according releases' git tag, which is 2023-01-13. The pgf-3.10.0.ebuild currently uses 2024-02-09, for reasons I don't recall.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d7e5f26a2b39773a3392555b16c47c0a95935e0 commit 1d7e5f26a2b39773a3392555b16c47c0a95935e0 Author: Florian Schmaus <flow@gentoo.org> AuthorDate: 2025-01-18 11:54:29 +0000 Commit: Florian Schmaus <flow@gentoo.org> CommitDate: 2025-01-18 11:55:51 +0000 dev-tex/pgf: fix pgf.revision.tex Upstream creates the pgf.revision.tex as part of its build.lua and the l3build invocation. We previously used a wrong date for pgf(re)visiondate and an outdated scheme of pgf.revision.tex. Closes: https://bugs.gentoo.org/948233 Signed-off-by: Florian Schmaus <flow@gentoo.org> dev-tex/pgf/pgf-3.1.10-r1.ebuild | 53 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
