Federico Gimenez Nieto wrote: > On Tue, 2010-05-25 at 13:30 +0300, Yavor Doganov wrote: > > I bet that once you fix the above in the usual way (i.e. conditionally > > define `debug', not `OPTLFAG'), you'll be able to reproduce it with > > gnustep-base/1.20.0.
> It is strange, conditionally defining 'debug=yes' leads to the same > NSDebugMLog related error... Ah, of course, sorry for confusing you. Not strange at all. Since debug=no is the default now, fixing the OPTFLAG issue has no effect on the FTBFS bug. You can pass ADDITIONAL_OBJCFLAGS=-DDEBUG to $(MAKE) in the build-stamp target and report a bug upstream that the package no longer builds with -Wl,--no-undefined. > Finally i managed to get rid of it (without noticing the > GSMethodList related error) by patching EOAccess/EOAttribute.m > (replacing all Foundation related import statements by > unconditionally importing Foundation/Foundation.h) Yes, this is the long-term solution, also the most suitable one for upstream. The workaround above is in case you don't want to add yet another patch. > but now the docs are not being generated, why might this be > happening? Give me some time to investigate. 99% gnustep-make related. (The GSMethodList FTBFS is gnustep-base/1.20.x-specific so you can't notice it in sid, but it will become RC when the new Base is uploaded in unstable. It is fixed upstream, easily backportable, but unfortunately the change is ABI-breaking for EOControl :-(.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
