New Ebuilds for SOPE 4.9_pre200908051100 (revision 1660) and one for SVN revision. Both of them use EAPI 2. Reproducible: Always
Created attachment 211962 [details] files/sope.envd
Created attachment 211964 [details, diff] files/sope-r1660-configure.patch
Created attachment 211966 [details, diff] files/sope-r1660-destdir.patch
Created attachment 211967 [details, diff] files/sope-r1660-MySQL4Channel.m.patch
Created attachment 211969 [details, diff] files/sope-r1660-NGHttp+WO.m.patch
Created attachment 211971 [details, diff] files/sope-r1660-NGImap4Client.patch
Created attachment 211973 [details, diff] files/sope-r1660-NGLogSyslogAppender.m.patch
Created attachment 211975 [details, diff] files/sope-r1660-NSDictionary+KVC.patch
Created attachment 211977 [details, diff] files/sope-r1660-NSNull+misc.m.patch
Created attachment 211979 [details, diff] files/sope-r1660-NSZoneMallocAtomic.patch
Created attachment 211980 [details, diff] files/sope-r1660-SOGo-fix.patch
Created attachment 211981 [details, diff] files/sope-r1660-SoOFS.patch
Created attachment 211982 [details, diff] files/sope-r1660-use_system_root.patch
Created attachment 211983 [details, diff] files/sope-r1660-WORepetition.m.patch
Created attachment 211984 [details] sope-4.9_pre200908051100.ebuild Ebuild for 4.9_pre200908051100 (that's revision 1660)
Created attachment 211985 [details] sope-999999.ebuild Ebuild for the SVN version.
The older Ebuilds from the GNUstep overlay where to chaotic (IMHO) so I rewrote them completely. Both of them are now EAPI 2 Ebuilds. There are still some open issues with SOGo that need to be addressed upstream. All of the patches that I have posted here are as well submitted upstream. If you want then I can post links to each of them. Just let me know.
I forgot to mention that I added an additional USE flag called "sogo". If you activate it then SOPE will be patched with the patches found in SOGo. I don't really see an reason NOT to use the patches but I don't know enough about GNUstep to know if SOPE on it's on is useful without the patches. So that's the reason I added this little USE flag. Maybe you can decide better if it is needed or not? I think without those patches it's damn hard to get SOPE to compile/install without issues when using gnustep-make >= 2.0. And in Gentoo I only found gnustep-make >= 2.0. Maybe we should remove that additional USE flag and patch SOPE in Gentoo always with the patches from SOGo? I don't know? What is your opinion?
Indeed, sogo patches include the one to support gnustep-make 2.0 (the only one w have), plus so far it's only used by sogo. So I'd say we always use the sogo patches, and we can add it later if the need ever arises The older version in gnustep overlay always had them enabled (just extracted from the sogo tarball and put in FILESDIR), and no one evert complained about it ;)
(In reply to comment #19) > Indeed, sogo patches include the one to support gnustep-make 2.0 (the only one > w have), plus so far it's only used by sogo. So I'd say we always use the sogo > patches, and we can add it later if the need ever arises > Okay. So do you want me to modify the Ebuild to take care of this and get rid of the "sogo" USE flag? > The older version in gnustep overlay always had them enabled (just extracted > from the sogo tarball and put in FILESDIR), > This saves definitely space but makes rsync longer (more stuff in FILESDIR) and makes maintenance for SOPE harder IMHO. > and no one evert complained about > it ;) > That does not mean that it is good to do that. I would have complained because I tried to bump the Ebuild from the gnustep overlay and did not understood one single bit from where this patch is coming and why it is there and where to get a newer version in case of bumping the Ebuild. IMHO we should then download SOGo as well with SOPE and patch SOPE with the patches directly from SOGo. That allows us to have greater control over what patches are needed for SOPE since we can say: SOPE XYZ needs patches from SOGo ABC
The sogo patchet in itself is big anyway, so a proper ebuild would have it on distfiles, so let's use the sogo tarball files anyway. Quick comments: The apache module built for me with same version (as 1660-200906161500 is r1660 also), it would be nice to have it (probably under apache2 USE flag, it it worked fine for you with nginx). I'll look at that while testing your ebuild Are the LDFLAGS checks in src_compile needed? compilation (in egnustep_make) failed with an error for me when testing with --as-needed without needing to check after make The rest looks fine (what's libFoundation use? for sogo or something else?)
(In reply to comment #21) > The sogo patchet in itself is big anyway, so a proper ebuild would have it on > distfiles, so let's use the sogo tarball files anyway. Quick comments: > > The apache module built for me with same version (as 1660-200906161500 is r1660 > also), it would be nice to have it (probably under apache2 USE flag, it it > worked fine for you with nginx). I'll look at that while testing your ebuild > > Are the LDFLAGS checks in src_compile needed? compilation (in egnustep_make) > failed with an error for me when testing with --as-needed without needing to > check after make > Can you please post the whole message/error that you got after egnustep_make? > The rest looks fine (what's libFoundation use? for sogo or something else?) > SOPE is not only used for SOGo. If some one wants to use OGo (OpenGroupware.org) then libFoundation is recommended. libFoundation can be used as an replacement for gnustep-base or additionally to gnustep-base.
Created attachment 212043 [details] files/47_mod_ngobjweb.conf
Created attachment 212045 [details] sope-4.9_pre200908051100.ebuild New Ebuild that has apach2 USE flag and does not any more have the sogo USE flag.
Created attachment 212046 [details] sope-999999.ebuild New Ebuild that has apach2 USE flag and does not any more have the sogo USE flag.
I did not include the Apache2 configuration for SOGo like it was done in the old gnustep overlay. The reason for that is that SOPE can be used for many things and adding a configuration inside SOPE for SOGo is the wrong place. If anyone has to deliver an Apach2 configuration for SOGo then it should/must be the SOGo Ebuild and not the SOPE ebuild. Keep in mind that SOPE is used not only for SOGo. If you install OGo then SOPE is used as. So if OGo should any time soon flow into Portage then it's OGo's responsibility to add an Apache2 configuration. Same like for SOGo.
I have btw not tested the Apache2 part. I don't know if the module is build or not. I think it should be build but I am not sure. Can you please test on your system if the module is build and if you can use it?
Any news?
(In reply to comment #28) > Any news? > I tried to use your ebuild for sope but I got this: * QA Notice: Package has poor programming practices which may compile * but will almost certainly crash on 64bit architectures. * * Function `ldap_init' implicitly converted to pointer at NGLdapConnection.m:96 * * Please file a bug about this at http://bugs.gentoo.org/ * with the maintaining herd of the package. * * * ERROR: gnustep-libs/sope-4.9_pre200908051100 failed. * Call stack: * misc-functions.sh, line 729: Called install_qa_check * misc-functions.sh, line 421: Called die * The specific snippet of code: * die "install aborted due to" \ * The die message: * install aborted due to poor programming practices shown above * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/temp/environment'. * This ebuild is from an overlay named 'gnustep': '/usr/local/portage/layman/gnustep/' * !!! post install failed; exiting. I am using Gentoo AMD64.Any help would be appreciated. By the way how can I compile gnustep without custom LDFLAGS to get rid of warning message.
Created attachment 215373 [details] gnustep-libs/sope/sope-4.9_pre200908051100.ebuild Better warning about custom LDFLAGS.
Created attachment 215374 [details] gnustep-libs/sope/sope-999999.ebuild Better warning about custom LDFLAGS.
(In reply to comment #29) > (In reply to comment #28) > > Any news? > > > I tried to use your ebuild for sope but I got this: > > * QA Notice: Package has poor programming practices which may compile > * but will almost certainly crash on 64bit architectures. > * > * Function `ldap_init' implicitly converted to pointer at > NGLdapConnection.m:96 > * > * Please file a bug about this at http://bugs.gentoo.org/ > * with the maintaining herd of the package. > * > * > * ERROR: gnustep-libs/sope-4.9_pre200908051100 failed. > * Call stack: > * misc-functions.sh, line 729: Called install_qa_check > * misc-functions.sh, line 421: Called die > * The specific snippet of code: > * die "install aborted due to" \ > * The die message: > * install aborted due to poor programming practices shown above > * > * If you need support, post the topmost build error, and the call stack if > relevant. > * A complete build log is located at > '/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/temp/environment'. > * This ebuild is from an overlay named 'gnustep': > '/usr/local/portage/layman/gnustep/' > * > !!! post install failed; exiting. > Could you try to install the SVN build (aka: sope-999999)? > I am using Gentoo AMD64.Any help would be appreciated. > By the way how can I compile gnustep without custom LDFLAGS to get rid of > warning message. > I changed the ebuild to only show a warning if you are using --add-needed or --as-needed. Does the error message still show up with the new ebuilds?
I changed the two ebuilds to only show the warning about LDFLAGS if one has compiled GNUstep with "--add-needed" and/or "--as-needed". I had endless troubles with SOPE/SOGo when I tried to build those ebuilds. It just did not worked and upstream was telling me that their build process is okay and it must be something that I have done wrong. I just could not find the error. So I downloaded their deb/rpm packages and tried to find out what is wrong with my binaries. And after some while I found out that if you are using "--add-needed" and/or "--as-needed" the binaries get wrongly compiled. I reported upstream about the issue but they don't care (http://www.scalableogo.org/bugs/view.php?id=262). A working library (for example "WEExtensions") should have those libraries dynamically linked (+/-. Depending on your build options are): --------------------------------------- nyx ~ # ldd -d /usr/GNUstep/System/Library/WOxElemBuilders-4.9/WEExtensions.wox/WEExtensions linux-gate.so.1 => (0xffffe000) libWEExtensions.so.4.9 => /usr/GNUstep/System/Library/Libraries/libWEExtensions.so.4.9 (0xb77b7000) libNGObjWeb.so.4.9 => /usr/GNUstep/System/Library/Libraries/libNGObjWeb.so.4.9 (0xb7596000) libNGMime.so.4.9 => /usr/GNUstep/System/Library/Libraries/libNGMime.so.4.9 (0xb74af000) libNGStreams.so.4.9 => /usr/GNUstep/System/Library/Libraries/libNGStreams.so.4.9 (0xb7466000) libNGExtensions.so.4.9 => /usr/GNUstep/System/Library/Libraries/libNGExtensions.so.4.9 (0xb73eb000) libEOControl.so.4.9 => /usr/GNUstep/System/Library/Libraries/libEOControl.so.4.9 (0xb73b3000) libXmlRpc.so.4.9 => /usr/GNUstep/System/Library/Libraries/libXmlRpc.so.4.9 (0xb7396000) libDOM.so.4.9 => /usr/GNUstep/System/Library/Libraries/libDOM.so.4.9 (0xb7361000) libSaxObjC.so.4.9 => /usr/GNUstep/System/Library/Libraries/libSaxObjC.so.4.9 (0xb7349000) libgnustep-base.so.1.19 => /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.19 (0xb7008000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6fe1000) libobjc.so.2 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/libobjc.so.2 (0xb6fc8000) libm.so.6 => /lib/libm.so.6 (0xb6fa2000) libc.so.6 => /lib/libc.so.6 (0xb6e5c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb6e2a000) libz.so.1 => /lib/libz.so.1 (0xb6e15000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb6dca000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb6c6f000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb6bc5000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb6b47000) libxslt.so.1 => /usr/lib/libxslt.so.1 (0xb6b0e000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb69d6000) libffi.so.5 => /usr/lib/libffi.so.5 (0xb69cf000) libbfd-2.18.so => /usr/i686-pc-linux-gnu/lib/libbfd-2.18.so (0xb6915000) libdl.so.2 => /lib/libdl.so.2 (0xb6911000) /lib/ld-linux.so.2 (0xb789b000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/libgcc_s.so.1 (0xb68f5000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb68e3000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb68de000) nyx ~ # --------------------------------------- Using "--add-needed" and/or "--as-needed" will way less libraries linked into the various SOPE/SOGo binaries/libraries.
With your new ebuild still no luck.The same error... No warning message about LDFLAGS But I went to /var/tmp/portage/gnustep-libs/sope-.../work and I typed: make install and surprise: no error. The problem is when gnustep-base_srl_install() runs.By the way NSDictionary+KVC.patch it's not working. Then emerge -O sogo(your ebuild also) and I have sogo up(but warning message about LDFLAGS).With errors but is up. I will try make it to interact with Thunderbird next days. I also compiled following http://www.scalableogo.org/english/support/faq/article/how-do-i-compile-sogo.html with no problems except the sope-ngobjweb-fix.diff wich was already applied.
(In reply to comment #34) > Hallo Catalin, > With your new ebuild still no luck.The same error... > what Ebuild? The 999999 (which is pulling SOPE from SVN) or the 4.9_pre200908051100 Ebuild? > No warning message about LDFLAGS > Good :) > But I went to /var/tmp/portage/gnustep-libs/sope-.../work > and I typed: make install and surprise: no error. > The problem is when gnustep-base_srl_install() runs. > Did you mean gnustep-base_src_install()? > By the way > NSDictionary+KVC.patch it's not working. > That is strange. If I check both the SVN and the other Ebuild then I have no issues applying that patch. Look here: 4.9_pre200908051100 Ebuild: ---------------------------------- nyx ~ # ebuild /mnt/gentoo.overlay/gnustep-libs/sope/sope-4.9_pre200908051100.ebuild unpack * 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: VUNET_Gentoo_Overlay * 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 * -Wl,-rpath=/usr/GNUstep/System/Library/Libraries * * 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 * Cleaning paths from GNUmakefile ... [ ok ] * 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 ] >>> Source unpacked in /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work nyx ~ # ---------------------------------- 999999 Ebuild: ---------------------------------- nyx ~ # ebuild /mnt/gentoo.overlay/gnustep-libs/sope/sope-999999.ebuild unpack * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: gnustep-libs/sope-999999 * REPO: VUNET_Gentoo_Overlay * 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 * -Wl,-rpath=/usr/GNUstep/System/Library/Libraries * * 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... * subversion update start --> * repository: http://svn.opengroupware.org/SOPE/trunk At revision 1664. * working copy: /usr/portage/distfiles/svn-src/sope/trunk mtn: doing anonymous pull; use -kKEYNAME if you need authentication mtn: connecting to inverse.ca mtn: finding items to synchronize: mtn: certificates | keys | revisions mtn: 16126 | 6 | 5354 mtn: bytes in | bytes out | certs in | revs in mtn: 157.1 k | 59.3 k | 84/84 | 21/21 mtn: successful exchange with inverse.ca mtn: updating along branch 'ca.inverse.sogo' mtn: selected update target 7f40c1e6007ec8d3584bcde31ed1008207df7d66 mtn: [left] 22c3c916089626376ade427022b35cf9bb49359a mtn: [right] 7f40c1e6007ec8d3584bcde31ed1008207df7d66 mtn: adding UnitTests mtn: adding UnitTests/GNUmakefile mtn: adding UnitTests/SOGoTest.h mtn: adding UnitTests/SOGoTest.m mtn: adding UnitTests/TestBSJSONAdditions.m mtn: adding UnitTests/sogo-tests.m mtn: updating ChangeLog mtn: updating NEWS mtn: updating SOPE/NGCards/ChangeLog mtn: updating SOPE/NGCards/iCalDateTime.m mtn: updating SOPE/sope-debian.diff mtn: updating SoObjects/Appointments/SOGoWebAppointmentFolder.m mtn: updating SoObjects/Appointments/iCalEntityObject+SOGo.m mtn: updating SoObjects/Appointments/product.plist mtn: updating SoObjects/SOGo/NSDictionary+BSJSONAdditions.m mtn: updating SoObjects/SOGo/NSScanner+BSJSONAdditions.m mtn: updating SoObjects/SOGo/NSString+Utilities.m mtn: updating SoObjects/SOGo/SOGoDefaults.plist mtn: updating UI/AdministrationUI/product.plist mtn: updating UI/Common/product.plist mtn: updating UI/Contacts/product.plist mtn: updating UI/MailPartViewers/product.plist mtn: updating UI/MailerUI/product.plist mtn: updating UI/MainUI/product.plist mtn: updating UI/PreferencesUI/product.plist mtn: updating UI/Scheduler/UIxAppointmentEditor.m mtn: updating UI/Scheduler/UIxCalMainView.h mtn: updating UI/Scheduler/UIxCalMainView.m mtn: updating UI/Scheduler/UIxDatePicker.m mtn: updating UI/Scheduler/UIxTimeDateControl.m mtn: updating UI/Scheduler/product.plist mtn: updating UI/Templates/SchedulerUI/UIxAppointmentEditor.wox mtn: updating UI/Templates/SchedulerUI/UIxCalMainView.wox mtn: updating UI/WebServerResources/SchedulerUI.js mtn: updated to base revision 7f40c1e6007ec8d3584bcde31ed1008207df7d66 * Applying sope-gsmake2.diff ... [ ok ] * Applying sope-patchset-r1664.diff ... [ ok ] * Applying sope-r1660-use_system_root.patch ... [ ok ] * Applying sope-r1660-SOGo-fix.patch ... [ ok ] * Applying sope-r1660-SoOFS.patch ... [ ok ] * Applying sope-r1660-MySQL4Channel.m.patch ... [ ok ] * Applying sope-r1660-NGLogSyslogAppender.m.patch ... [ ok ] * Applying sope-r1660-NGHttp+WO.m.patch ... [ ok ] * Cleaning paths from GNUmakefile ... [ ok ] >>> Source unpacked in /var/tmp/portage/gnustep-libs/sope-999999/work nyx ~ # ---------------------------------- The SVN Ebuild does not use NSDictionary+KVC.patch since it is not needed any more. But for the 4.9 edition you still need it. > Then emerge -O sogo(your ebuild also) and I have sogo up(but warning message > about LDFLAGS). With errors but is up. > Ahh. Yes. I need to change that LDFLAGS checking in SOGo Ebuild as well. > I will try make it to interact with Thunderbird next days. > Could you try to use the 999999 versions of the Ebuilds? They work much better in Gentoo then the other (older) Ebuilds. > I also compiled following > http://www.scalableogo.org/english/support/faq/article/how-do-i-compile-sogo.html > with no problems except the sope-ngobjweb-fix.diff wich was already applied. > Yes. That patch is already applied to stock SOGo.
(In reply to comment #35) > (In reply to comment #34) > > > Hallo Catalin, > > > > With your new ebuild still no luck.The same error... > > > what Ebuild? The 999999 (which is pulling SOPE from SVN) or the > 4.9_pre200908051100 Ebuild? > Hi Steve, 4.9_pre200908051100 Ebuild With 999999 the same error: "...Function `ldap_init' implicitly converted to pointer at NGLdapConnection.m:96...." and manual make install from /var/tpm/portage/gnustep... > > > No warning message about LDFLAGS > > > Good :) > > > > But I went to /var/tmp/portage/gnustep-libs/sope-.../work > > and I typed: make install and surprise: no error. > > The problem is when gnustep-base_srl_install() runs. > > > Did you mean gnustep-base_src_install()? > Yes, sorry src_install() { cd "${S}" unset LDFLAGS newenvd "${FILESDIR}"/sope.envd 99sope \ || die "Failed installing env.d script" *** gnustep-base_src_install use apache2 && apache-module_src_install } > > > By the way > > NSDictionary+KVC.patch it's not working. > > > That is strange. If I check both the SVN and the other Ebuild then I have no > issues applying that patch. Look here: > > > 4.9_pre200908051100 Ebuild: > ---------------------------------- > nyx ~ # ebuild > /mnt/gentoo.overlay/gnustep-libs/sope/sope-4.9_pre200908051100.ebuild unpack > * 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: VUNET_Gentoo_Overlay > * 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 > * -Wl,-rpath=/usr/GNUstep/System/Library/Libraries > * > * 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 > * Cleaning paths from GNUmakefile ... [ ok ] > * 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 ] > >>> Source unpacked in /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work > nyx ~ # > ---------------------------------- > > > 999999 Ebuild: > ---------------------------------- > nyx ~ # ebuild /mnt/gentoo.overlay/gnustep-libs/sope/sope-999999.ebuild unpack > * checking ebuild checksums ;-) ... [ ok ] > * checking auxfile checksums ;-) ... [ ok ] > * checking miscfile checksums ;-) ... [ ok ] > * CPV: gnustep-libs/sope-999999 > * REPO: VUNET_Gentoo_Overlay > * 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 > * -Wl,-rpath=/usr/GNUstep/System/Library/Libraries > * > * 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... > * subversion update start --> > * repository: http://svn.opengroupware.org/SOPE/trunk > At revision 1664. > * working copy: /usr/portage/distfiles/svn-src/sope/trunk > > mtn: doing anonymous pull; use -kKEYNAME if you need authentication > mtn: connecting to inverse.ca > mtn: finding items to synchronize: > mtn: certificates | keys | revisions > mtn: 16126 | 6 | 5354 > mtn: bytes in | bytes out | certs in | revs in > mtn: 157.1 k | 59.3 k | 84/84 | 21/21 > mtn: successful exchange with inverse.ca > mtn: updating along branch 'ca.inverse.sogo' > mtn: selected update target 7f40c1e6007ec8d3584bcde31ed1008207df7d66 > mtn: [left] 22c3c916089626376ade427022b35cf9bb49359a > mtn: [right] 7f40c1e6007ec8d3584bcde31ed1008207df7d66 > mtn: adding UnitTests > mtn: adding UnitTests/GNUmakefile > mtn: adding UnitTests/SOGoTest.h > mtn: adding UnitTests/SOGoTest.m > mtn: adding UnitTests/TestBSJSONAdditions.m > mtn: adding UnitTests/sogo-tests.m > mtn: updating ChangeLog > mtn: updating NEWS > mtn: updating SOPE/NGCards/ChangeLog > mtn: updating SOPE/NGCards/iCalDateTime.m > mtn: updating SOPE/sope-debian.diff > mtn: updating SoObjects/Appointments/SOGoWebAppointmentFolder.m > mtn: updating SoObjects/Appointments/iCalEntityObject+SOGo.m > mtn: updating SoObjects/Appointments/product.plist > mtn: updating SoObjects/SOGo/NSDictionary+BSJSONAdditions.m > mtn: updating SoObjects/SOGo/NSScanner+BSJSONAdditions.m > mtn: updating SoObjects/SOGo/NSString+Utilities.m > mtn: updating SoObjects/SOGo/SOGoDefaults.plist > mtn: updating UI/AdministrationUI/product.plist > mtn: updating UI/Common/product.plist > mtn: updating UI/Contacts/product.plist > mtn: updating UI/MailPartViewers/product.plist > mtn: updating UI/MailerUI/product.plist > mtn: updating UI/MainUI/product.plist > mtn: updating UI/PreferencesUI/product.plist > mtn: updating UI/Scheduler/UIxAppointmentEditor.m > mtn: updating UI/Scheduler/UIxCalMainView.h > mtn: updating UI/Scheduler/UIxCalMainView.m > mtn: updating UI/Scheduler/UIxDatePicker.m > mtn: updating UI/Scheduler/UIxTimeDateControl.m > mtn: updating UI/Scheduler/product.plist > mtn: updating UI/Templates/SchedulerUI/UIxAppointmentEditor.wox > mtn: updating UI/Templates/SchedulerUI/UIxCalMainView.wox > mtn: updating UI/WebServerResources/SchedulerUI.js > mtn: updated to base revision 7f40c1e6007ec8d3584bcde31ed1008207df7d66 > * Applying sope-gsmake2.diff ... [ ok ] > * Applying sope-patchset-r1664.diff ... [ ok ] > * Applying sope-r1660-use_system_root.patch ... [ ok ] > * Applying sope-r1660-SOGo-fix.patch ... [ ok ] > * Applying sope-r1660-SoOFS.patch ... [ ok ] > * Applying sope-r1660-MySQL4Channel.m.patch ... [ ok ] > * Applying sope-r1660-NGLogSyslogAppender.m.patch ... [ ok ] > * Applying sope-r1660-NGHttp+WO.m.patch ... [ ok ] > * Cleaning paths from GNUmakefile ... [ ok ] > >>> Source unpacked in /var/tmp/portage/gnustep-libs/sope-999999/work > nyx ~ # > ---------------------------------- > >>> Unpacking SOGo-1.1.0.tar.gz to /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work >>> Unpacking sope-trunk-r1660-200908051100.tar.gz to /var/tmp/portage/gnustep-libs/sope-4.9_pre200908051100/work * Cleaning paths from GNUmakefile ... [ ok ] * 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 ... * Failed Patch: sope-r1660-NSDictionary+KVC.patch ! * ( /usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-NSDictionary+KVC.patch ) * * Include in your bugreport the contents of: > The SVN Ebuild does not use NSDictionary+KVC.patch since it is not needed any > more. But for the 4.9 edition you still need it. > > > > > Then emerge -O sogo(your ebuild also) and I have sogo up(but warning message > > about LDFLAGS). With errors but is up. > > > Ahh. Yes. I need to change that LDFLAGS checking in SOGo Ebuild as well. > > > > I will try make it to interact with Thunderbird next days. > > > Could you try to use the 999999 versions of the Ebuilds? They work much better > in Gentoo then the other (older) Ebuilds. > The same problem with that ebuild, i need to run mannualy make install and sope-r1660-use_system_root.patch not working also samba sope # emerge sope Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) gnustep-libs/sope-999999 from gnustep * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * This profile has not been tested thoroughly and is not considered to be * a supported server profile at this time. For a supported server * profile, please check the Hardened project (http://hardened.gentoo.org). * This profile is merely a convenience for people who require a more * minimal profile, yet are unable to use hardened due to restrictions in * the software being used on the server. This profile should also be used * if you require GCC 4.1 or Glibc 2.4 support. If you don't know if this * applies to you, then it doesn't and you should probably be using * Hardened, instead. * * You seem to have compiled GNUstep with custom LDFLAGS. SOPE is very * sensitive regarding custom LDFLAGS. 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... * subversion update start --> * repository: http://svn.opengroupware.org/SOPE/trunk At revision 1664. * working copy: /usr/portage/distfiles/svn-src/sope/trunk mtn: doing anonymous pull; use -kKEYNAME if you need authentication mtn: connecting to inverse.ca mtn: finding items to synchronize: mtn: certificates | keys | revisions mtn: 16189 | 6 | 5375 mtn: bytes in | bytes out | certs in | revs in mtn: 1.1 k | 1.3 k | 0/0 | 0/0 mtn: successful exchange with inverse.ca mtn: updating along branch 'ca.inverse.sogo' mtn: already up to date at 7f40c1e6007ec8d3584bcde31ed1008207df7d66 * Applying sope-r1660-use_system_root.patch ... * Failed Patch: sope-r1660-use_system_root.patch ! * ( /usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-use_system_root.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/gnustep-libs/sope-999999/temp/sope-r1660-use_system_root.patch-21980.out * * ERROR: gnustep-libs/sope-999999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2978: Called epatch '/usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-use_system_root.patch' * environment, line 1452: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * The die message: * Failed Patch: sope-r1660-use_system_root.patch! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/gnustep-libs/sope-999999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnustep-libs/sope-999999/temp/environment'. * This ebuild is from an overlay named 'gnustep': '/usr/local/portage/layman/gnustep/' * >>> Failed to emerge gnustep-libs/sope-999999, Log file: >>> '/var/tmp/portage/gnustep-libs/sope-999999/temp/build.log' * Messages for package gnustep-libs/sope-999999: * * You seem to have compiled GNUstep with custom LDFLAGS. SOPE is very * sensitive regarding custom LDFLAGS. 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. * * Messages for package gnustep-libs/sope-999999: * * You seem to have compiled GNUstep with custom LDFLAGS. SOPE is very * sensitive regarding custom LDFLAGS. 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. * * Failed Patch: s ! * ( /usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-use_system_root.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/gnustep-libs/sope-999999/temp/sope-r1660-use_system_root.patch-21980.out * * ERROR: gnustep-libs/sope-999999 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2978: Called epatch '/usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-use_system_root.patch' * environment, line 1452: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * The die message: * Failed Patch: sope-r1660-use_system_root.patch! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/gnustep-libs/sope-999999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnustep-libs/sope-999999/temp/environment'. * This ebuild is from an overlay named 'gnustep': '/usr/local/portage/layman/gnustep/' * > > > I also compiled following > > http://www.scalableogo.org/english/support/faq/article/how-do-i-compile-sogo.html > > with no problems except the sope-ngobjweb-fix.diff wich was already applied. > > > Yes. That patch is already applied to stock SOGo. >
(In reply to comment #36) > 4.9_pre200908051100 Ebuild > Okay. Thanks. > With 999999 the same error: > "...Function `ldap_init' implicitly converted to pointer at > NGLdapConnection.m:96...." > and manual make install from /var/tpm/portage/gnustep... > You should report that upstream. > Yes, sorry > > src_install() { > cd "${S}" > unset LDFLAGS > newenvd "${FILESDIR}"/sope.envd 99sope \ > || die "Failed installing env.d script" > *** gnustep-base_src_install > use apache2 && apache-module_src_install > } > Aha. That is another story. Do you have files/sope.envd in your overlay? I think you have forgotten to copy that file. Could that be? If this is the case then the error about converted pointers in ldap_init is not the problem you have. It's the missing files/sope.envd that is breaking your build. > * Failed Patch: sope-r1660-NSDictionary+KVC.patch ! > * ( > /usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-NSDictionary+KVC.patch > ) > * > * Include in your bugreport the contents of: > Could you attach the file mentioned after the above line? Maybe it would be better to send those files directly to my mail since attaching them here in b.g.o will only blow up Bugzilla for nothing. > The same problem with that ebuild, i need to run mannualy make install > and sope-r1660-use_system_root.patch not working also > [...] > > /var/tmp/portage/gnustep-libs/sope-999999/temp/sope-r1660-use_system_root.patch-21980.out > > * > * ERROR: gnustep-libs/sope-999999 failed. > * Call stack: > * ebuild.sh, line 49: Called src_unpack > * environment, line 2978: Called epatch > '/usr/local/portage/layman/gnustep/gnustep-libs/sope/files/sope-r1660-use_system_root.patch' > * environment, line 1452: Called die > * The specific snippet of code: > * die "Failed Patch: ${patchname}!"; > * The die message: > * Failed Patch: sope-r1660-use_system_root.patch! > * > * If you need support, post the topmost build error, and the call stack if > relevant. > * A complete build log is located at > '/var/tmp/portage/gnustep-libs/sope-999999/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/gnustep-libs/sope-999999/temp/environment'. > * This ebuild is from an overlay named 'gnustep': > '/usr/local/portage/layman/gnustep/' > * > > >>> Failed to emerge gnustep-libs/sope-999999, Log file: > > >>> '/var/tmp/portage/gnustep-libs/sope-999999/temp/build.log' > Please do what the Ebuild is telling you. Attach those files here or send them to me by mail. I can not guess what is going wrong by just looking at the error output. How have you downloaded the patches attached here in this bug report? You know that you need to download them binary and not with copy & paste?
Catalin, according to your mail the patches are working now. You should always download patches directly from b.g.o :) Okay. Now about the other error you have: Function `ldap_init' implicitly converted to pointer at NGLdapConnection.m:96 There was already an old bug entry in their tracker regarding that issue. I just posted that the error is still here with 4.9 and with SVN trunk. The bug report is here -> http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=2031 I don't think they will do anything soon regarding that issue (judging based on my experience with them in the past). Anyway... fixing that implicit conversation to a pointer for ldap_init is easy. I will attach a patch and new Ebuilds. That should eliminate the build problem you have. I will however not fix the other warnings. They should not stop you from compiling SOPE on your arch.
Created attachment 215614 [details] gnustep-libs/sope/sope-4.9_pre200908051100.ebuild
Created attachment 215616 [details] gnustep-libs/sope/sope-999999.ebuild
Created attachment 215617 [details, diff] gnustep-libs/sope/files/sope-r1660-NGLdapConnection.m.patch
(In reply to comment #41) > Created an attachment (id=215617) [details] > gnustep-libs/sope/files/sope-r1660-NGLdapConnection.m.patch > Steve, It's the same error.... On your system it's working.It's not amd64?
> It's the same error.... > Okay, okay. The quick and dirty patch did not work. Let me post the other one (the lazy approach). I tested it under my AMD64 and it's working. The only left QA notice is: --------------------- * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * UnixSignalHandler.m:364: warning: implicit declaration of function 'sigpause' ---------------------
Created attachment 215638 [details, diff] gnustep-libs/sope/files/sope-r1660-LDAP_deprecated.patch
Created attachment 215640 [details] gnustep-libs/sope/sope-4.9_pre200908051100.ebuild
Created attachment 215641 [details] gnustep-libs/sope/sope-999999.ebuild
(In reply to comment #44) > Created an attachment (id=215638) [details] > gnustep-libs/sope/files/sope-r1660-LDAP_deprecated.patch > Steve, Bingo !!! It's working A few minor issues: No init.d script. If I copy sogo.initd then I got the error : samba Admin # /etc/init.d/sogod start * Starting SOGo service ... /sbin/start-stop-daemon: unrecognized option '--stdout' Try `/sbin/start-stop-daemon --help' for more information. [ !! ] If I remove the line with '--stdout' then I got samba # /etc/init.d/sogod start ... [ !! ] and nothing in log Then I run sogo.initd-r3 start and I got : samba Admin # /ebuilds/sogo.initd-r3 start * Can't find sogod Copied missing file to /usr/GNUstep/System/Tools/Admin/sogod and samba Admin # /ebuilds/sogo.initd-r3 start * Starting SOGo service ... /usr/GNUstep/System/Tools/Admin/sogod: error while loading shared libraries: libSOGo.so.1: cannot open shared object file: No such file or directory It needs that libraries to be in /USR/GNUStep/Local/library..... I did that then bingo again : samba bkp # /ebuilds/sogo.initd-r3 start * Starting SOGo service ... 2010-01-08 15:17:59.457 sogod[3810] starting SOGo (build root@samba 201001061627) 2010-01-08 15:17:59.458 sogod[3810] Note: vmem size check enabled: shutting down app when vmem > 384 MB Jan 08 15:17:59 sogod [3810]: SNS support disabled. Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> scanning SOGo products in: /var/lib/sogo/GNUstep/Library/SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> scanning SOGo products in: /usr/GNUstep/Local/Library/SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: Mailer.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: MailerUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: SchedulerUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: ContactsUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: AdministrationUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: Appointments.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: MainUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: Contacts.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: CommonUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: MailPartViewers.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: PreferencesUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> scanning SOGo products in: /usr/GNUstep/System/Library/SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: Mailer.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: MailerUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: SchedulerUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: ContactsUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: AdministrationUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: Appointments.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: MainUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: Contacts.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: CommonUI.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: MailPartViewers.SOGo Jan 08 15:17:59 sogod [3810]: <0x0x1adbe30[SOGoProductLoader]> register SOGo product: PreferencesUI.SOGo 2010-01-08 15:17:59.504 sogod[3810] Note: fetching full mail header. 2010-01-08 15:17:59.504 sogod[3810] Note(SOGoMailObject): using constant etag for mail parts: '"imap4url_1_1_126"' 2010-01-08 15:17:59.504 sogod[3810] Note(SOGoMailBodyPart): using constant etag for mail parts: '"imap4url_1_1_126"' 2010-01-08 15:17:59.505 sogod[3810] Note: using SOGo mail spool folder: /tmp/ 2010-01-08 15:17:59.505 sogod[3810] Note: using SOGo mail spool folder: /tmp/ 2010-01-08 15:17:59.505 sogod[3810] Note: using drafts folder named: 'Inbox.Drafts' 2010-01-08 15:17:59.505 sogod[3810] Note: using shared-folders name: 'Shared Folders' 2010-01-08 15:17:59.505 sogod[3810] Note: using other-users-folders name: 'Other Users' Jan 08 15:17:59 sogod [3810]: |SOGo| WOHttpAdaptor listening on address *:20000 Then samba Library # /etc/init.d/sogod start * Starting SOGo service ... [ ok ] but nothing in the log file(got to do with unrecognized option '--stdout') Thanks,
(In reply to comment #45) > Created an attachment (id=215640) [details] > gnustep-libs/sope/sope-4.9_pre200908051100.ebuild > sorry, after a new emerge sogo the files were in the place they where suppose to be .....weird but the error unrecognized option '--stdout' is still on an nothiing is written in log file
Catalin, > Bingo !!! It's working > tell me what you like but we Gentoo users are good. Most of us at least know how to help each other :) > A few minor issues: > Please post your comments regarding SOGo in the bug report of SOGo and not in the one from SOPE. Okay? btw: I updated the SOGo Ebuilds.
(In reply to comment #49) > Catalin, > > > Bingo !!! It's working > > > tell me what you like but we Gentoo users are good. Most of us at least know > how to help each other :) because we love it and we dont't like push button distro’s. > > > A few minor issues: > > > Please post your comments regarding SOGo in the bug report of SOGo and not in > the one from SOPE. Okay? btw: I updated the SOGo Ebuilds. > ok , now I'm looking at new ebuilds of sope and I will post in the bug report from sope
(In reply to comment #50) > because we love it and we dont't like push button distro’s. > Most users that I know like the flexibility of Gentoo, USE flags, etc... bush button or not. > ok , now I'm looking at new ebuilds of sope and I will post in the bug report > from sope > :)
Finally could review it, most of the ebuild is fine, just some nitpicks: KEYWORDS: only set ~arch ones, and on arches you tested cd "${S}": compile, install, ... and other phases already start in ${S} LDFLAGS: even if it's a PITA, globally unsetting LDFLAGS is bad practice :( ( http://www.gentoo.org/proj/en/qa/asneeded.xml or http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html ). Here it will probably be using append-ldflags to filter the --as-needed, AND fix gnustep-make (sigh, yet another new item on my TODO list), as the ebuild should honour current LDFLAGS, not the ones from gnustep-make With EAPI-2 ebuilds, epatch and other source preparation should be in src_prepare 4.9_pre200908051100 is in the gnustep overlay now, will see for live ebuild after a pass on sogo
(In reply to comment #52) > Finally could review it, most of the ebuild is fine, just some nitpicks: > > KEYWORDS: only set ~arch ones, and on arches you tested > cd "${S}": compile, install, ... and other phases already start in ${S} > LDFLAGS: even if it's a PITA, globally unsetting LDFLAGS is bad practice :( ( > http://www.gentoo.org/proj/en/qa/asneeded.xml or > http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html > ). > Here it will probably be using append-ldflags to filter the --as-needed, AND > fix gnustep-make (sigh, yet another new item on my TODO list), as the ebuild > should honour current LDFLAGS, not the ones from gnustep-make > With EAPI-2 ebuilds, epatch and other source preparation should be in > src_prepare > > 4.9_pre200908051100 is in the gnustep overlay now, will see for live ebuild > after a pass on sogo > Thanks for the feedback.
Created attachment 216230 [details] gnustep-libs/sope/sope-999999.ebuild Updating the SVN build to include the feedback from Bernard Cafarelli
Created attachment 216231 [details] gnustep-libs/sope/sope-999999.ebuild Removing unneeded stuff from SVN Ebuild and simplifying the Ebuild.
Hi Steve, I have build sope and sogo from the scratch on another computer and I confirm you that everything it's ok.Keep up the good work!
(In reply to comment #56) > Hi Steve, > > I have build sope and sogo from the scratch on another computer and I confirm > you that everything it's ok.Keep up the good work! > Hallo Catalin, all the non live Ebuilds for SOPE/SOGo are already committed by Bernard Cafarelli to the gnustep overlay.
(In reply to comment #57) > (In reply to comment #56) > > Hi Steve, > > > > I have build sope and sogo from the scratch on another computer and I confirm > > you that everything it's ok.Keep up the good work! > > > Hallo Catalin, all the non live Ebuilds for SOPE/SOGo are already committed by > Bernard Cafarelli to the gnustep overlay. > I know.I have used those ebuilds.One more thing : there is nothing in the log file although I have 'debug' use flag enabled
(In reply to comment #58) > I know.I have used those ebuilds.One more thing : there is nothing in the log > file although I have 'debug' use flag enabled > That's more or less a SOGo question and has nothing to do with the Ebuilds. You should use the Gentoo forums for such questions or you could address the developers of SOGo directly. I will however make now an exception and post here a solution. But only this time. Please don't continue using b.g.o like a forum. When you switch to user sogo you should be able to execute "defaults -u sogo read sogod". That should print out the config from SOGo. Look for entry "WOLogFile". If that is not set then set it and restart SOGo. If you don't know how to set it then please consult the SOGo documentation.
(In reply to comment #59) > (In reply to comment #58) > > I know.I have used those ebuilds.One more thing : there is nothing in the log > > file although I have 'debug' use flag enabled > > > That's more or less a SOGo question and has nothing to do with the Ebuilds. You > should use the Gentoo forums for such questions or you could address the > developers of SOGo directly. > > I will however make now an exception and post here a solution. But only this > time. Please don't continue using b.g.o like a forum. > > When you switch to user sogo you should be able to execute "defaults -u sogo > read sogod". That should print out the config from SOGo. Look for entry > "WOLogFile". If that is not set then set it and restart SOGo. If you don't know > how to set it then please consult the SOGo documentation. > ok
And -9999 is in overlay too now (yell if I forgot a file), now I need to find and fix how to make gnustep-make behave and respect our _current LDFLAGS and friends
(In reply to comment #61) > And -9999 is in overlay too now (yell if I forgot a file), now I need to find > and fix how to make gnustep-make behave and respect our _current LDFLAGS and > friends > One little thing. This here: epatch "${EMTN_STORE_DIR}"/SOGo/SOPE/sope-patchset-r1660.diff This is not going to work because SOGo is checked out from their Monotone repository and that patch set is not limited to revision 1660 from SOPE. If I check their current repository then that patch is already at revision 1664: -rw-r--r-- 1 root portage 232K Jan 6 17:08 /usr/portage/distfiles/mtn-src/SOGo/SOPE/sope-patchset-r1664.diff Could you not change that line to be again like in the Ebuild that I have attached here?: epatch "${EMTN_STORE_DIR}"/SOGo/SOPE/sope-patchset-r*.diff Another thing here: epatch "${FILESDIR}"/${PN}-r1660-use_system_root.patch You have added that patch to the overlay but have renamed it to: sope-use_system_root.patch Could you rename it back to: sope-r1660-use_system_root.patch
Thanks for the check, use_system_root patch name fixed I've also switched to the -r*.diff for sogo patchset, indeed better for the live ebuild. You're courageous tracking all this patchset in a live ebuild!
(In reply to comment #63) > Thanks for the check, use_system_root patch name fixed > > I've also switched to the -r*.diff for sogo patchset, indeed better for the > live ebuild. You're courageous tracking all this patchset in a live ebuild! > Well... I do my best. A lot of the patches are from me. Took me some time to get SOPE/SOGo running. The first attempts where fruitless and I switched to live hoping that would help. But that did not help. So I had to search for patches and had to make patches, where needed. I consider this bug report (for now) as fixed. Okay? People will anyway come here to b.g.o if they should have issues and I am doing almost daily a checkout from SVN/Monotone and compile both packages on my setup. So the chance that I find a potential bug before the big mass of Gentoo users is finding them is pretty high :)
