| Summary: | [gnustep overlay] gnustep-libs/sope-9999 fails to emerge (Failed Patch: sope-gsmake2.diff) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hannes Erven <h.e> |
| Component: | New packages | Assignee: | Gentoo Gnustep project <gnustep> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | steeeeeveee |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Thanks for the report! CC-ing Steve, who has done most of the work on the current ebuilds :) It may be worth taking a look at sope-4.9_pre20090805110 build error too? (In reply to comment #1) > Thanks for the report! CC-ing Steve, who has done most of the work on the > current ebuilds :) > It may be worth taking a look at sope-4.9_pre20090805110 build error too? > Thanks for adding me. (In reply to comment #0) > I'd like to setup "live" sogo from the gnustep overlay. The emerge of sope > fails: > > # emerge "=gnustep-libs/sope-9999" > > >>> Preparing source in /var/tmp/portage/gnustep-libs/sope-9999/work/sope ... > * Applying sope-gsmake2.diff ... > > * Failed Patch: sope-gsmake2.diff ! > * ( /usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-gsmake2.diff ) > * > * Include in your bugreport the contents of: > * > * /var/tmp/portage/gnustep-libs/sope-9999/temp/sope-gsmake2.diff.out > That is a known issue. Read here this thread: http://mail.opengroupware.org/pipermail/developer/2010-March/003948.html Especially this here: http://mail.opengroupware.org/pipermail/developer/2010-March/003959.html > > As there is a compile error when emerging non-live versions I cannot simply use > them as a replacement. > I don't understand that statement. Are you saying that you can not compile sope-4.9_pre200908051100? You should be able to compile. I just tried now: ------------------------ nyx ~ # ebuild /var/lib/layman/gnustep/gnustep-libs/sope/sope-4.9_pre200908051100.ebuild compile * sope-trunk-r1660-200908051100.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * SOGo-1.1.0.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking sope-trunk-r1660-200908051100.tar.gz ;-) ... [ ok ] * checking SOGo-1.1.0.tar.gz ;-) ... [ ok ] * CPV: gnustep-libs/sope-4.9_pre200908051100 * REPO: gnustep * USE: elibc_glibc kernel_linux ldap mysql userland_GNU x86 * * You seem to have compiled GNUstep with custom LDFLAGS: * -Wl,-O1 * -Wl,--add-needed * -Wl,--as-needed * -Wl,--hash-style=both * -Wl,--sort-common * * SOPE is very sensitive regarding custom LDFLAGS. Especially with: * --add-needed * --as-needed * * If your SOPE install does not work as expected then please re-emerge SOPE * and your GNUstep (base and make) without any LDFLAGS before filing bugs. * >>> Unpacking source... >>> Unpacking sope-trunk-r1660-200908051100.tar.gz to /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work >>> Unpacking SOGo-1.1.0.tar.gz to /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work >>> Source unpacked in /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work >>> Preparing source in /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope ... * Applying sope-gsmake2.diff ... [ ok ] * Applying sope-patchset-r1660.diff ... [ ok ] * Applying sope-r1660-SOGo-fix.patch ... [ ok ] * Applying sope-r1660-NSZoneMallocAtomic.patch ... [ ok ] * Applying sope-r1660-SoOFS.patch ... [ ok ] * Applying sope-r1660-WORepetition.m.patch ... [ ok ] * Applying sope-r1660-NSDictionary+KVC.patch ... [ ok ] * Applying sope-r1660-NSNull+misc.m.patch ... [ ok ] * Applying sope-r1660-LDAP_deprecated.patch ... [ ok ] * Cleaning paths from GNUmakefile ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope ... GNUstep environment: system: /usr/GNUstep/System local: /usr/GNUstep/Local user: /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/homedir/GNUstep path: /usr/GNUstep/System:/usr/GNUstep/Network:/usr/GNUstep/Local:/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/homedir/GNUstep flat: yes arch: i686-pc-linux-gnu combo: gnu-gnu-gnu Note: will install in GNUSTEP_LOCAL_ROOT: /usr/GNUstep/Local Configuration: FHS: install in GNUstep tree debug: no strip: no prefix: /usr/GNUstep/Local frameworks: gstep: /usr/GNUstep/System/Library/Makefiles config: /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope/config.make script: /usr/GNUstep/System/Library/Makefiles/GNUstep.sh creating: /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope/config.make optional library found: xml2 optional library found: ldap required library found: ssl failed to link optional library: pq optional library found: sqlite3 optional library found: mysqlclient configuring NGStreams library .... done (log in config-NGStreams.log). >>> Source configured. >>> Compiling source in /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope ... [... big output of compile mambo jambo ...] make[2]: Leaving directory `/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope/sope-ldap/samples' make[1]: Leaving directory `/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work/sope/sope-ldap' >>> Source compiled. nyx ~ # ------------------------ If you are not able to compile any of the 4.9 pre releases then I would personally be interested to know more about your system. Could you post output of "emerge --info" and other vital information? > Reproducible: Always > > Steps to Reproduce: > > Actual Results: > Beginning of the requested file: > > ***** sope-gsmake2.diff ***** > > ============================= > > PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < > '/usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-gsmake2.diff' > > ============================= > patching file configure > patching file sope-ldap/samples/GNUmakefile > Hunk #1 FAILED at 1. > Hunk #2 FAILED at 9. > Hunk #3 FAILED at 22. > 3 out of 3 hunks FAILED -- saving rejects to file > sope-ldap/samples/GNUmakefile.rej > patching file sope-ldap/NGLdap/GNUmakefile > Hunk #1 FAILED at 1. > Hunk #2 FAILED at 13. > Hunk #3 FAILED at 60. > 3 out of 3 hunks FAILED -- saving rejects to file > sope-ldap/NGLdap/GNUmakefile.rej > patching file sope-ldap/GNUmakefile > Hunk #1 FAILED at 1. > 1 out of 1 hunk FAILED -- saving rejects to file sope-ldap/GNUmakefile.rej > patching file GNUmakefile > patching file sope-gdl1/PostgreSQL/GNUmakefile.preamble > Hunk #1 FAILED at 27. > 1 out of 1 hunk FAILED -- saving rejects to file > sope-gdl1/PostgreSQL/GNUmakefile.preamble.rej > patching file sope-gdl1/PostgreSQL/GNUmakefile > > [...] > > PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < > '/usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-gsmake2.diff' > > ============================= > missing header for unified diff at line 5 of patch > can't find file to patch at input line 5 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -------------------------- > |Index: configure > |=================================================================== > |--- configure (révision 1632) > |+++ configure (copie de travail) > -------------------------- > No file to patch. Skipping patch. > 19 out of 19 hunks ignored > can't find file to patch at input line 315 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > [...] > > > > > Perhaps the problem was introduced with Rev#1701 of SOPE; it seems that it now > already includes at least a part of the patches that the ebuild tries to > perform. > > > r1701 | sreitenbach | 2010-02-23 13:30:59 +0100 (Die, 23. Feb 2010) | 2 Zeilen > > revert back to revision 1664, because import of sogo-patches failed > Do you guys want me to enhance the SOPE Ebuild to allow a checkout from an earlier revision? Currently 99999 Ebuild is downloading trunk and the nature of live Ebuilds is that they can break. So either we wait till SOPE trunk gets fixed or we add additional functionality into the live Ebuild to allow choosing of an older revision. @Bernard: What would you like me to do? // Steve Thank you for looking into the issue and the mailing list pointers. It seems I haven't searched thouroughly enough before opening the bug, sorry. Nevertheless, I'd like to install sogo. [ebuild N ] gnustep-libs/sope-4.9_pre200908051100 USE="apache2 ldap mysql -debug -doc -libFoundation -postgres -sqlite" 7,692 kB [1] [ebuild N ] gnustep-apps/sogo-1.2.1 USE="mysql -debug -doc -logrotate -postgres" 3,224 kB [1] sope-4.9_pre installs cleanly as you expected, but then sogo fails to emerge: i686-pc-linux-gnu-gcc SOGoCalendarProxy.m -c \ -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -DGSWARN -DGSDIAGNOSE -Wno-import -O2 -march=pentium4 -fno-strict-aliasing -fgnu-runtime -fconstant-string-class=NSConstantString -I.. -I../.. -I../../SOPE -I../../SOPE/ -I. -I/var/tmp/portage/gnustep-apps/sogo-1.2.1/temp/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/Headers -I/usr/GNUstep/System/Library/Headers \ -o obj/SOGoCalendarProxy.m.o SOGoCalendarProxy.m: In Funktion »-[SOGoCalendarProxy davResourceType]«: SOGoCalendarProxy.m:66: Fehler: »XMLNS_CalendarServerOrg« nicht deklariert (erste Benutzung in dieser Funktion) SOGoCalendarProxy.m:66: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt SOGoCalendarProxy.m:66: Fehler: für jede Funktion in der er auftritt.) make[3]: *** [obj/SOGoCalendarProxy.m.o] Fehler 1 make[2]: *** [Appointments.all.wobundle.variables] Fehler 2 make[2]: Leaving directory `/var/tmp/portage/gnustep-apps/sogo-1.2.1/work/SOGo-1.2.1/SoObjects/Appointments' make[1]: *** [internal-all] Fehler 2 make[1]: Leaving directory `/var/tmp/portage/gnustep-apps/sogo-1.2.1/work/SOGo-1.2.1/SoObjects' make: *** [internal-all] Fehler 2 ... which is also described here http://mail.opengroupware.org/pipermail/sogo/2010-January/004713.html . The solution suggested there is to update sope, but that would be sope-9999 which also fails due to the patch issues. So at this moment, no sogo ebuild for me :-/ Thanks again. (In reply to comment #4) > Thank you for looking into the issue > No problem. Helping a Gentoo user is an honor for another Gentoo user :) > and the mailing list pointers. > Was easy since I started that thread :) > It seems I > haven't searched thouroughly enough before opening the bug, sorry. > No problem. > Nevertheless, I'd like to install sogo. > Okay. > [ebuild N ] gnustep-libs/sope-4.9_pre200908051100 USE="apache2 ldap mysql > -debug -doc -libFoundation -postgres -sqlite" 7,692 kB [1] > [ebuild N ] gnustep-apps/sogo-1.2.1 USE="mysql -debug -doc -logrotate > -postgres" 3,224 kB [1] > > > sope-4.9_pre installs cleanly as you expected, > Perfect. > but then sogo fails to emerge: > > i686-pc-linux-gnu-gcc SOGoCalendarProxy.m -c \ > -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 > -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -DGSWARN -DGSDIAGNOSE -Wno-import > -O2 -march=pentium4 -fno-strict-aliasing -fgnu-runtime > -fconstant-string-class=NSConstantString -I.. -I../.. -I../../SOPE > -I../../SOPE/ -I. > -I/var/tmp/portage/gnustep-apps/sogo-1.2.1/temp/GNUstep/Library/Headers > -I/usr/GNUstep/Local/Library/Headers -I/usr/GNUstep/System/Library/Headers \ > -o obj/SOGoCalendarProxy.m.o > SOGoCalendarProxy.m: In Funktion »-[SOGoCalendarProxy davResourceType]«: > SOGoCalendarProxy.m:66: Fehler: »XMLNS_CalendarServerOrg« nicht deklariert > (erste Benutzung in dieser Funktion) > SOGoCalendarProxy.m:66: Fehler: (Jeder nicht deklarierte Bezeichner wird nur > einmal aufgeführt > SOGoCalendarProxy.m:66: Fehler: für jede Funktion in der er auftritt.) > make[3]: *** [obj/SOGoCalendarProxy.m.o] Fehler 1 > make[2]: *** [Appointments.all.wobundle.variables] Fehler 2 > make[2]: Leaving directory > `/var/tmp/portage/gnustep-apps/sogo-1.2.1/work/SOGo-1.2.1/SoObjects/Appointments' > make[1]: *** [internal-all] Fehler 2 > make[1]: Leaving directory > `/var/tmp/portage/gnustep-apps/sogo-1.2.1/work/SOGo-1.2.1/SoObjects' > make: *** [internal-all] Fehler 2 > > ... which is also described here > http://mail.opengroupware.org/pipermail/sogo/2010-January/004713.html . > LOL. The message is from me as well :) > The > solution suggested there is to update sope, but that would be sope-9999 which > also fails due to the patch issues. So at this moment, no sogo ebuild for me > :-/ > Hmm.... switching quickly to German: Gib nicht auf! Erst wenn Du akzeptierst, dass Du verloren hast, dann hast Du verloren. So it might be that 1.2.1 is failing (right now) but have you tried 1.2.0? If 1.2.0 is failing (which I don't expect) then try 1.1.0-r1. If all of them fail then I think it's time to do some coding (from my part) and add that possibility to choose an explicit revision while using the live Ebuild for SOPE. Let me know about your success/failure when trying an older SOGo version. > Thanks again. > No problem at all. Sorry Hannes. It's late and sometime one can't see the forest because of the trees. If you want the live Ebuild to checkout the last working revision then no changes to the Ebuild are needed (that is the beauty of Gentoo). Just execute: ----------------- ESVN_REVISION=1664 emerge -v sope ----------------- This should checkout revision 1664 (as suggested by the SOGo people). But I know from my own personal experience that the last working SOPE revision is 1700. So you might have better results with SOGo by emerging SOPE with: ----------------- ESVN_REVISION=1700 emerge -v sope ----------------- @Bernard: I think you could close this bug report if Hannes has nothing to object. // Steve Thanks again, will try. But: emerge: there are no ebuilds to satisfy "dev-util/monotone". (dependency required by "gnustep-libs/sope-9999" [ebuild]) (dependency required by "sope" [argument]) Yeah, because monotone has been moved to dev-vcs recently: 05 Mar 2010; Sebastian Pipping <sping@gentoo.org> +files/50monotone-gentoo.el, +files/monotone-0.36.initd, +monotone-0.45.ebuild, +files/hooks.lua, +files/monotone.confd, +files/read-permissions, +files/write-permissions, +metadata.xml: Move to dev-vcs category So please update the DEPENDS. I've done that locally, and now everything installed cleanly (sope-rev#1700, sogo-1.2.1). So thanks again, WORKSFORME. DEPENDs updated :) (In reply to comment #7) > Thanks again, will try. But: > > emerge: there are no ebuilds to satisfy "dev-util/monotone". > (dependency required by "gnustep-libs/sope-9999" [ebuild]) > (dependency required by "sope" [argument]) > > Yeah, because monotone has been moved to dev-vcs recently: > > 05 Mar 2010; Sebastian Pipping <sping@gentoo.org> > +files/50monotone-gentoo.el, +files/monotone-0.36.initd, > +monotone-0.45.ebuild, +files/hooks.lua, +files/monotone.confd, > +files/read-permissions, +files/write-permissions, +metadata.xml: > Move to dev-vcs category > > So please update the DEPENDS. > I've done that locally, and now everything installed cleanly (sope-rev#1700, > sogo-1.2.1). > So thanks again, WORKSFORME. > Cool! You see? I told you. Don't give up! Gentoo is just a beautiful Distro. :) If you should have any other feedback regarding SOPE/SOGo then let us know. Patches are as usual very welcome. Just post then on b.g.o. |
I'd like to setup "live" sogo from the gnustep overlay. The emerge of sope fails: # emerge "=gnustep-libs/sope-9999" >>> Preparing source in /var/tmp/portage/gnustep-libs/sope-9999/work/sope ... * Applying sope-gsmake2.diff ... * Failed Patch: sope-gsmake2.diff ! * ( /usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-gsmake2.diff ) * * Include in your bugreport the contents of: * * /var/tmp/portage/gnustep-libs/sope-9999/temp/sope-gsmake2.diff.out As there is a compile error when emerging non-live versions I cannot simply use them as a replacement. Reproducible: Always Steps to Reproduce: Actual Results: Beginning of the requested file: ***** sope-gsmake2.diff ***** ============================= PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < '/usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-gsmake2.diff' ============================= patching file configure patching file sope-ldap/samples/GNUmakefile Hunk #1 FAILED at 1. Hunk #2 FAILED at 9. Hunk #3 FAILED at 22. 3 out of 3 hunks FAILED -- saving rejects to file sope-ldap/samples/GNUmakefile.rej patching file sope-ldap/NGLdap/GNUmakefile Hunk #1 FAILED at 1. Hunk #2 FAILED at 13. Hunk #3 FAILED at 60. 3 out of 3 hunks FAILED -- saving rejects to file sope-ldap/NGLdap/GNUmakefile.rej patching file sope-ldap/GNUmakefile Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file sope-ldap/GNUmakefile.rej patching file GNUmakefile patching file sope-gdl1/PostgreSQL/GNUmakefile.preamble Hunk #1 FAILED at 27. 1 out of 1 hunk FAILED -- saving rejects to file sope-gdl1/PostgreSQL/GNUmakefile.preamble.rej patching file sope-gdl1/PostgreSQL/GNUmakefile [...] PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < '/usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-gsmake2.diff' ============================= missing header for unified diff at line 5 of patch can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: configure |=================================================================== |--- configure (révision 1632) |+++ configure (copie de travail) -------------------------- No file to patch. Skipping patch. 19 out of 19 hunks ignored can't find file to patch at input line 315 Perhaps you used the wrong -p or --strip option? The text leading up to this was: [...] Perhaps the problem was introduced with Rev#1701 of SOPE; it seems that it now already includes at least a part of the patches that the ebuild tries to perform. r1701 | sreitenbach | 2010-02-23 13:30:59 +0100 (Die, 23. Feb 2010) | 2 Zeilen revert back to revision 1664, because import of sogo-patches failed