Created attachment 530166 [details] Build log checking for freetype-config... no configure: error: did not find freetype-config required for system freetype2 library
The solution is to update m4/kpse-freetype2-flags.m4 to try pkg-config first and fall back to freetype-config if that fails. For the changes to take effect you must run the provided ./reautoconf script (which takes forever). patches attached
Created attachment 530660 [details, diff] texlive-freetype2.patch try pkg-config freetype2 before freetype-config
Created attachment 530662 [details] texlive_core-2017-r4.ebuild updated ebuild
Created attachment 530664 [details, diff] texlive_core-2017-r3.ebuild.patch patch to the existing ebuild to make the changes easier to see.
From freetype's documentation: The `configure' script no longer installs `freetype-config' by default. For backwards compatibility, a new configure option `--enable-freetype-config' is provided that reverts this decision.
(In reply to maurerpe from comment #2) > Created attachment 530660 [details, diff] [details, diff] > texlive-freetype2.patch > > try pkg-config freetype2 before freetype-config The fallback to freetype-config doesn't make much sense, given that all freetype versions in the tree support pkg-config. (In reply to Nikos Chantziaras from comment #5) > From freetype's documentation: > > The `configure' script no longer installs `freetype-config' by default. For > backwards compatibility, a new configure option `--enable-freetype-config' > is provided that reverts this decision. Yes, we know. :)
(In reply to maurerpe from comment #3) > Created attachment 530662 [details] > texlive_core-2017-r4.ebuild > > updated ebuild please attach a diff to make this more readable but from the look of it you are using a custom autoreconf script without adding proper autotools deps, so that won't work I'm not sure if that's a great idea, but the rule has always been to use autotools.eclass for this.
(In reply to Alexis Ballier from comment #7) > (In reply to maurerpe from comment #3) > > Created attachment 530662 [details] > > texlive_core-2017-r4.ebuild > > > > updated ebuild > > please attach a diff to make this more readable I did. It is the texlive_core-2017-r3.ebuild.patch attachment. > but from the look of it you are using a custom autoreconf script without > adding proper autotools deps, so that won't work > > I'm not sure if that's a great idea, but the rule has always been to use > autotools.eclass for this. I am using upstream's provided reautoconf script. It goes through a couple dozen directories and reruns all the necessary autoconf tools. It takes a couple of minutes to run. I don't think it is as simple as adding autotools.eclass and calling autoreconf. I expect that it will require a manual list of every autoconf directory and calling autoreconf on each one. I am not sure the best way to do this. Do you have an example of an ebuild that does this?
> The fallback to freetype-config doesn't make much sense, given that all > freetype versions in the tree support pkg-config. By fallback, I simply mean that I didn't delete the old code that uses freetype-config. My usual approach to these patches is to not break existing functionality. My experience has been that this accelerates upstream adoption as it is easier for them to verify it doesn't break existing use cases. Which reminds me, I need to submit this upstream. I have now emailed tex-live@tug.org. They don't seem to have a bug tracker.
> (In reply to Alexis Ballier from comment #7) > > but from the look of it you are using a custom autoreconf script without > > adding proper autotools deps, so that won't work > I expect that it will require a > manual list of every autoconf directory and calling autoreconf on each one. > I am not sure the best way to do this. Do you have an example of an ebuild > that does this? I think I may have figured it out by copying lines from the upstream provided script. Would something like: list=". auxdir/auxsub libs utils texk `find libs utils texk -type d -name ac | sed 's,/ac\$,,'`" for dir in $list; do (cd $dir; autoreconf) done be acceptable? If so, I can provide an updated ebuild & ebuild patch.
(In reply to maurerpe from comment #9) > > The fallback to freetype-config doesn't make much sense, given that all > > freetype versions in the tree support pkg-config. > > By fallback, I simply mean that I didn't delete the old code that uses > freetype-config. My usual approach to these patches is to not break > existing functionality. My experience has been that this accelerates > upstream adoption as it is easier for them to verify it doesn't break > existing use cases. *shrug* FreeType supports pkg-config since its version 2.1.5, which was released in 2003. So I don't think you'll do upstream a favour by keeping the cruft.
freetype-2.9.1 went stable and now contends with app-text/texlive-core-2017-r3 (has <media-libs/freetype-2.9.1 in DEPEND)
Maybe it's better to provide a patch for the generated files instead of going through the (unreasonably long) reconf step during emerge?
I filed a bug for changing the current dep to freetype-2.9.1-r1 which does not provide freetype-config: https://bugs.gentoo.org/655650 I'm not doing a git PR since I don't know if we really want the revbump or not (it looks like we might not, in order to get stable users the bug fixes of freetype 2.9.1.) This is obviously a temporary solution until a patch to use pkg-config is available.
(In reply to Nikos Chantziaras from comment #14) > I filed a bug for changing the current dep to freetype-2.9.1-r1 which does > not provide freetype-config Uh, typo. It should be "which DOES provide freetype-config."
*** Bug 655650 has been marked as a duplicate of this bug. ***
Guys, this bug breaks stable users. Please fix it ASAP!
(In reply to Anton Bolshakov from comment #17) > Guys, this bug breaks stable users. Please fix it ASAP! This has been already fixed for the time being. See bug 655650.
(In reply to Nikos Chantziaras from comment #18) > This has been already fixed for the time being. See bug 655650. Thanks, apologies. A mirror which I'm using was slow to pick up this change.
The dependency patch of https://bugs.gentoo.org/655650#c7 is wrong now See following comment at: https://bugs.gentoo.org/655650#c8 (I mention here, because that bug is closed, so normaly nobody cares)
This was starting to get annoying, so I gave it a shot. Unfortunately some of our eltpatch magic (the stuff you only understand when your name starts with M) consistently fails even after forcing all eauto* functions into the build system using a crowbar and a sonic screwdriver. Thus, I went for a suboptimal but working solution: added a mini-patch for freetype and regenerated all the autoconf files in a vanilla tarball, then diff'ed against the original. (The resulting patch is 600kByte xz-compressed.) Also backported an upstream patch for poppler-0.64.0. Not sure if that code actually makes sense, but if upstream thinks so... Testing done: builds against current freetype, builds against poppler-0.63, builds against poppler-0.64. Committing as texlive-core-2017-r4 without keywords for runtime testing and review.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=edc56c40bdf0d98d3d01dd13a4368c462c58be4e commit edc56c40bdf0d98d3d01dd13a4368c462c58be4e Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2018-05-20 20:25:47 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2018-05-20 20:26:10 +0000 app-text/texlive-core: Revbump for poppler-0.64 and recent freetype Bug: https://bugs.gentoo.org/655052 Package-Manager: Portage-2.3.38, Repoman-2.3.9 app-text/texlive-core/Manifest | 1 + .../files/texlive-core-2017-poppler064.patch | 118 +++++++ app-text/texlive-core/texlive-core-2017-r4.ebuild | 366 +++++++++++++++++++++ 3 files changed, 485 insertions(+)
Added to package.keywords and it works fine here.
I added '=app-text/texlive-core-2017-r4 **' to package.accept_keywords and it emerged successfully.
(In reply to O. William McClung from comment #24) > I added '=app-text/texlive-core-2017-r4 **' to package.accept_keywords and > it emerged successfully. I did the same and got the same result. I think this is ready to keyword now.
Works for me as well.
Hi, As the patch from Andreas seems to fix the bug, do you think that it’s time to stabilise -r4? This bug still prevent media-libs/freetype-2.9.1-r3 from being installed.
*** Bug 656238 has been marked as a duplicate of this bug. ***
I will CC arches in a week if nobody disagrees
amd64 stable
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8f2f048c792333669aa3029dacd4d0eb853f688b commit 8f2f048c792333669aa3029dacd4d0eb853f688b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-06-24 01:36:41 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-06-24 01:37:36 +0000 app-text/texlive-core: stable 2017-r4 for ia64, bug #655052 Bug: https://bugs.gentoo.org/655052 Package-Manager: Portage-2.3.40, Repoman-2.3.9 RepoMan-Options: --include-arches="ia64" app-text/texlive-core/texlive-core-2017-r4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3e7a7904585b72ce06249eebfc19d446f4e8f126 commit 3e7a7904585b72ce06249eebfc19d446f4e8f126 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-06-24 19:49:03 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-06-24 20:20:25 +0000 app-text/texlive-core: stable 2017-r4 for ppc64, bug #655052 Bug: https://bugs.gentoo.org/655052 Package-Manager: Portage-2.3.40, Repoman-2.3.9 RepoMan-Options: --include-arches="ppc64" app-text/texlive-core/texlive-core-2017-r4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Stable on alpha.
x86 stable
arm stable
arm64 stable
s390 stable
Looking good on ppc. # cat texlive-core-655052.report USE tests started on So 22. Jul 12:55:25 CEST 2018 FEATURES=' test' USE='' succeeded for =app-text/texlive-core-2017-r4 USE='-X cjk doc luajittex -source -tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X cjk -doc -luajittex source -tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='X -cjk -doc luajittex source -tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X cjk doc luajittex source -tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X -cjk doc -luajittex -source tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X -cjk doc luajittex -source tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X cjk -doc luajittex source tk -xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X cjk doc -luajittex -source -tk xetex' succeeded for =app-text/texlive-core-2017-r4 USE='X cjk doc -luajittex source -tk xetex' succeeded for =app-text/texlive-core-2017-r4 USE='X cjk -doc luajittex -source tk xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X -cjk doc luajittex -source tk xetex' succeeded for =app-text/texlive-core-2017-r4 USE='-X -cjk -doc luajittex source tk xetex' succeeded for =app-text/texlive-core-2017-r4 revdep tests started on So 22. Jul 21:37:48 CEST 2018 FEATURES=' test' USE='' succeeded for dev-texlive/texlive-langitalian FEATURES=' test' USE='' succeeded for dev-texlive/texlive-context FEATURES=' test' USE='' succeeded for dev-texlive/texlive-metapost FEATURES=' test' USE='' succeeded for dev-texlive/texlive-langczechslovak FEATURES=' test' USE='' succeeded for dev-texlive/texlive-bibtexextra FEATURES=' test' USE='' succeeded for dev-texlive/texlive-langcjk FEATURES=' test' USE='' succeeded for dev-texlive/texlive-langenglish FEATURES=' test' USE='' succeeded for dev-texlive/texlive-luatex FEATURES=' test' USE='' succeeded for dev-texlive/texlive-publishers FEATURES=' test' USE='' succeeded for dev-texlive/texlive-langcyrillic
ppc stable (thanks to ernsteiswuerfel)
sparc done, the omfonts problem is likely no regression.
hppa dropped
