Apparently, though unproven, at 21:34 on Tuesday 17 May 2011, Mick did opine thusly:
> On 17 May 2011 08:01, Alan McKinnon <[email protected]> wrote: > > Apparently, though unproven, at 08:23 on Tuesday 17 May 2011, Mick did > > opine > > > > thusly: > >> eukit >= 1.0.999 > >> ehal > >> ) were not met: > >> > >> No package 'ehal' found > > > > e17 from svn works fine here. > > > > What version are you trying to install? > > These are the packages I tried to install/update: I can confirm that e17 builds just fine without hal, I remerged everything here today with a fresh svn update. I compared by USE to yours and they are much the same apart from ofono (not relevant) and I have ukit enabled. You are running x86 (32 bit) right? I see your USE has (-hal) whereas mine is -hal. man emerge implies that means the flag is forced off somehow, so I would be interested to see what e17 thinks it should do on your machine. Please emerge enlightenment (just that one package) and post the section just before this: checking for E_REMOTE... yes checking for E_IMC... yes checking for E_THUMB... yes It's the 5 lines or so immediately before the error in your first post and will mention hal_mount and eeze. [snip] > > When emerge ran, did it check out the > > latest code for first first? > > You lost me here! O_O Looks like a bad paste error. I meant if you use the regular overlay and check out a fresh svn update with each emerge (i.e. not using an old checkout with updates from the repo disabled). I see elsewhere you do use fresh checkouts. > > The hal stuff in e17 has been iffy for a while. > > Right, but I have excluded all hal USE flags as far as I can tell, > that's why I cannot understand why x11-wm/enlightenment-9999 failed > with that error. Well, the gentoo part works. It's the e17 ./configure step that is iffy. raster HATES use flags with a passion; automagic deps is the only way to go in his worldview. Quite obviously this will lead to problems on gentoo with no real way to disable support for something you do have installed. (Just because you have libXYZ installed is not a good reason to force support on for it everywhere that might use it.) > > Anyway, tonight it failed right on the first package: > ==================================== > > >>> Emerging (1 of 10) dev-libs/eina-9999 from enlightenment [snip] Well, whaddaya know. For once it wasn't cedric who broke it. Looks like commit r59468 to eina at 17:45 by tasn did it. > eina_binbuf_template_c.x:140: error: conflicting types for > 'eina_binbuf_length_get' > ../../src/include/eina_binbuf.h:209: note: previous declaration of > 'eina_binbuf_length_get' was here > eina_amalgamation.c:17936: error: redefinition of '__STRBUF_MAGIC_STR' > eina_amalgamation.c:1222: note: previous definition of > '__STRBUF_MAGIC_STR' was here > make[3]: *** [libeina_la-eina_amalgamation.lo] Error 1 [snip] > What's causing this one? I don't see an easy way to workaround this apart from reverting r59468. So, just skip past eina, you already have a copy from earlier that built correctly and portage won't catch version difference seeing as everything is -9999 > BTW, any idea when DR17 will make it into the portage tree? I suppose it would have to exist first :-) EFL-1.0.0 is released since three months ago so it could go into the tree. It probably isn't there yet because the most useful app using it - the window manager - is still unreleased. I reckon vapier or barbieri would be the right people to answer that question. -- alan dot mckinnon at gmail dot com
