Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)
On Wed, May 26, 2010 at 10:03:10PM +0300, Yavor Doganov wrote: Federico Gimenez Nieto wrote: but now the docs are not being generated, why might this be happening? Give me some time to investigate. 99% gnustep-make related. The API docs are built, only the manual is not. This is because in 2.4.0 the way subprojects are built was redesigned (introducing GNUSTEP_USE_PARALLEL_AGGREGATE to allow parallel building of subprojects), so make doesn't even recurse into the Documentation directory since it's not present in the SUBPROJECTS variable at the time the makefile is parsed. Just move the aggregate.make include in GNUmakefile.in *after* the doc conditional; that should fix the problem. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)
On Wed, 2010-05-26 at 22:03 +0300, Yavor Doganov wrote: Thanks, now it is bulding without problems, it is uploaded at mentors [1] [1] http://mentors.debian.net/debian/pool/main/g/gnustep-dl2/gnustep-dl2_0.12.0-3.dsc (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 :-(.) Is there any chance to prevent this FTBFS while keeping EOControl in good shape? Cheers, Federico signature.asc Description: This is a digitally signed message part
Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)
Federico Gimenez Nieto wrote: Thanks, now it is bulding without problems, it is uploaded at mentors IMHO it is useless to make an upload to sid fixing the current RC bug now, because you'd need a sourceful upload for the transition anyway, and the GNUstep stack (including gnustep-dl2) is not releasable with the current combination of the core libraries. So the focus must be to prepare for the transition -- you can (and should) tag the bug pending to avoid duplicate efforts, but an upload to sid would be a waste. Your (and your sponsor's) call, of course. (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 :-(.) Is there any chance to prevent this FTBFS while keeping EOControl in good shape? Possibly, for someone familiar with the code. However, I doubt upstream would be interested to assist here, because there were other ABI breaks since the last release (IOW: it is kinda pointless for them to try to avoid this ABI break for the sake of one distro when they've certainly introduced others.) What I suggest (to avoid introducing debian-specific soname and passing through NEW twice) is the following: 1. Discuss with upstream their plans for the new release -- when it is supposed to happen, which libraries will have the soname bumped (All for consistency? Only those with incompatible changes? Etc.) 2. Depending on 1), upload to experimental either a SVN trunk snapshot with the new upstream soname(s) (provided they'll keep the ABI stable until the actual release), or upload with a minimalistic fix for the FTBFS + debian-specific soname, again in experimental. Experimental, because it would allow you/us to control precisely the moment for the upload to sid (when the release team gives green light for the transition) -- NEW processing can be very slow or very fast, so it's best to avoid any uncertainty and eventual delays during the GNUstep transition. I call the second scenario unfortunate, because you'd have to bump the soname *again* when you package next upstream release, whenever that happens. (In addition, something as important as a library interface version is best to coincide with upstream, in an ideal world even among different distros.) 3. Another variant, dirty and unprofessional in my opinion, is to keep the soname(s) the same regardless of the ABI-incompatible changes. This was done numerous times in the past for Objective-C libraries in Debian (including core libraries), almost always not deliberately and discovered post-factum. We'll survive, but it is a very dangerous path to follow. I advise you to avoid this at all costs. The fact that there are no reverse dependencies within the Debian archive is more or less irrelevant -- it means there won't be RC bugs to other packages because of the silent ABI break, but some users of the library will surely be unpleasantly surprised. Besides, I intend to fix steptalk (#583100) to build the GDL2 bundle so there will be at least one reverse dependency. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)
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... 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) but now the docs are not being generated, why might this be happening? Cheers, Federico signature.asc Description: This is a digitally signed message part
Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)
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
Bug#583006: Bug#581934: gnustep-dl2: FTBFS with gnustep-base/1.20.0: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function)
clone 583006 -1 # The libs are built with -g, but not DBModeler. retitle -1 gnustep-dl2: (Partially) broken nostrip handling with gnustep-make/2.4.x severity -1 important thanks В 12:54 +0200 на 23.05.2010 (нд), Federico Gimenez Nieto написа: On Mon, 2010-05-17 at 12:46 +0300, Yavor Doganov wrote: This package fails to build with gnustep-base/1.20.0 with the following error: EONSAddOns.m:102: error: ‘GSMethodList’ undeclared (first use in this function) I'm getting a different error on build, it reads as follows: obj/EOAccess.obj/EOAttribute.m.o: In function `-[EOAttribute(EOAttributeValueMapping) validateValue:]': /home/fgimenez/packages/gnustep-dl2/gnustep-dl2-0.12.0/EOAccess/EOAttribute.m:1622: undefined reference to `NSDebugMLog' collect2: ld returned 1 exit status This is a different issue. As of gnustep-make/2.4.0, the default is debug=no, so -DDEBUG is no longer in OBJCFLAGS, which causes FTBFS due to the way gnustep-dl2's own headers are designed. I am not able to get the GSMethodList related error, how can i reproduce it? 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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
