Attaching an ebuild for freetype 2.1.7, based on 2.1.4-r1 Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 20675 [details] ebuild
Created attachment 20773 [details] cleaner ebuild This one uses econf and standard make commands instead of what was before. I'm not sure why there was the other stuff before, but it seems to work with just the standard commands now.
It appears that with this version of freetype, one cannot say #include <freetype/freetype.h> anymore. you need #include <ft2build.h> #include FT_FREETYPE_H instead. It appears in /usr/X11R6/include/X11/Xft/Xft.h line 35, we have the incorrect older way, and so if you install this 2.1.7, it breaks anything that has to include Xft.h Which means the Xft.h needs to be patched. I haven't discovered the problem in any other program yet, but I suspect it might crop up.
Dunno if we should add this at this time, needs a lot of changes. We should make a list of what includes freetype.h the old way or maybe we should fix freetype to allow the old way for now.
If I run fgrep freetype * in /usr/include or /usr/X11R6/inclue, i don't get many hits, but i do get fontconfig libwmf pango Now thats not to say I have everything that uses ft2 installed, but my guess is the number might be quite small. In the new freetype.h, there is this part right at the top: #ifndef FT_FREETYPE_H #error "`ft2build.h' hasn't been included yet!" #error "Please always use macros to include FreeType header files." #error "Example:" #error " #include <ft2build.h>" #error " #include FT_FREETYPE_H" #endif I wonder if we just take that out, perhaps it might work.
don't think so, we should probably also add the given statements. Current gtk2/qt apps shouldnt really need to dep on freetype directly anymore, but a lot of older stuff does. A quick dep grep in the portage tree should pick up most of them, but probably not even all.
what do you mean 'add the given statements'? I think this change was actually around a while ago, so some apps that require freetype2 already use the new kind of include. (I remember seeing it in the changelog a while ago) Its just that it used to be that you could do it either way, and now only the new way works.
why not throw it into unstable and see what breaks thats the whole point of unstable :)
i don't think so.. ~ is not for known not working stuff. Read the policy. I dunno why most of the users and even the large part of the devs think that these days, it's a sort of self-sustaining myth that everyone tells eachother. In short see ~ as testing for ebuilds, not for the packages themselves. Only known stable and working stuff should be any one of the two trees. package.mask would be the place to give this testing to some extent. Anyway, current apps may be adapting yes, the problem lies with old packages that are still useful, but most likely won't get another update. Plan for now is to get the non 'new-style' 2.1.5 in (which was delayed because of a lack of time on my side) and check out 2.1.7 local and then move it into p.mask soon-ish.
looks like they fixed up the freetype includes in the gtk-devel versions.. just a matter of time until others catch up.
yes, but it will be some months before the 2.3 series will be in the tree (2.4 by then). But we should probably steadily go make fixes, so i'll try to add it one of these days to p.mask as said.
2.1.7 is in the tree, p.mask though.
