This is a replacement for bug #24441 which was the original request for a Chandler ebuild. Notes that may help in the construction of an ebuild can be found at http://wiki.osafoundation.org/bin/view/Chandler/GentooBuildNotes Reproducible: Always Steps to Reproduce:
Look at http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 for ebuild howto.
The current version (0.4) says "Do not trust your data with this version.", so I don't see much point in working on an ebuild now. The wxwidgets herd is watching Chandler though and will have an ebuild when its a little more mature.
I recently posted ebuilds (0.5.02 and a live cvs) and updated the Gentoo instructions here: http://wiki.osafoundation.org/bin/view/Chandler/GentooBuildNotes I've been looking for an appropriate Gentoo group to discuss when Chandler integration might start to make sense; I'm going to swing on over to the wxwidgets herd for some basic discussion.
I'll take a look at it again.
Re-opening for intial testing as there are now ebuilds available.
Created attachment 57139 [details] First-draft ebuild for Chandler 0.5.02 Attaching basic ebuild for ~x86 Chandler build. May not detect GCJ conditions properly. Review needed.
Created attachment 57140 [details] First-draft ebuild for "live CVS" Chandler Attaching ebuild for ~x86 "live CVS" Chandler. Though live CVS have problems, this software is under rapid development, and Gentoo users may wish to track and contribute back to development. Unsure of proper version to use for this HEAD ebuild. Needs review.
Created attachment 59816 [details] First-draft ebuild for "live subversion" Chandler OSAF (upstream provider for ebuild) has switched to subversion for development, instead of CVS. The CVS ebuild should no longer be used, and this subversion-based ebuild superceeds it. Attaching ebuild for ~x86 "live subversion" Chandler. Though live subversion ebuilds have problems and are not recommended, this software is under rapid development, and Gentoo users may wish to track and contribute back to development. Unsure of proper version number to use for live ebuilds. Ebuild needs review. Build and runtime dependencies have not been carefully tested.
Chandler 0.6 was released last month. It's apparently the first release they consider to be "experimentally usable". Here's the Linux download link: http://downloads.osafoundation.org/chandler/releases/0.6/Chandler_linux_0.6.i386.rpm
ok .. I'm playing with version 0.6.1 ... will use the currently availible ebuild and see if I can get something working. anybody wanna help .. let me know ..
**adding to CC** I started to look at the ebuild. If you need some help let me know, I am not the greatest at writing ebuilds, but I can normally hack one together that works :/
I edited the build using a mixture of the svn (only the check for gcc/gcj) and changed the downloaded source, it started compiling fine, but then ended with this. after the >>> Install, man: prepallstrip: and strip: .... QA Notice: the following files contain insecure RUNPATH's Please file a bug about this at http://bugs.gentoo.org/ For more information on this issue, kindly review: http://bugs.gentoo.org/81745 /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_stat /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_verify /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_checkpoint /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_upgrade /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_archive /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_deadlock /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_recover /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_printlog /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_dump /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/db/bin/db_load /var/tmp/portage/chandler-0.6.1/work/external/release/db/lib usr/lib/chandler/0.6.1/release/lib/python2.4/lib-dynload/_bsddb.so QA Notice: the following files contain runtime text relocations Text relocations force the dynamic linker to perform extra work at startup, waste system resources, and may pose a security risk. On some architectures, the code may not even function properly, if at all. Please include this file in your report: /var/tmp/portage/chandler-0.6.1/temp/scanelf-textrel.log TEXTREL usr/lib/chandler/0.6.1/release/icu/lib/libicuio.so.34.0 TEXTREL usr/lib/chandler/0.6.1/release/lib/python2.4/lib-dynload/bz2.so QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. Please include this file in your report: /var/tmp/portage/chandler-0.6.1/temp/scanelf-exec.log RWX --- --- usr/lib/chandler/0.6.1/release/icu/bin/uconv RWX --- --- usr/lib/chandler/0.6.1/release/lib/libcrypto.so.0.9.7 !!! ERROR: app-office/chandler-0.6.1 failed. Call stack: ebuild.sh, line 1894: Called dyn_install !!! Aborting due to serious QA concerns with RUNPATH/RPATH !!! If you need support, post the topmost build error, and the call stack if relevant. I haven't seen these QA notices before, I will have to read more.
Created attachment 89357 [details] Bugfixed chandler-9999.ebuild Bugfix error : "no external dir found"
Has this progressed any further? I'd like to test this ebuild.
I also want to be tester of this ebuild. Is there any progress ?...
Reassigning to maintainer-wanted for more exposure to people looking for packages that aren't maintained. This doesn't mean the wxWidgets herd won't be interested in maintaining this, if no-one else is, at a later date once the already maintained packages are back in shape.
I didn't realize Chandler was still alive and kicking. I was under the impression it was a dead project.
M. Edward Borasky wrote: > I didn't realize Chandler was still alive and kicking. It'd be pretty easy to actually check on what's up the project: check the blog or downloads. http://chandlerproject.org/ The Chandler project has produced regular releases of both of their products which seem to always contain substantial updates. A major funder recently left but few open source projects have funding in the first place. There aren't many (any?) other open source projects which support multi-party sharing of calendars or tasks so this seems a valuable ebuild to have around.
chandler is a struggling project that hasn't produced a finished product in six years. the founder just left. i'm uncomfortable to add a project that is the subject of a book on failed software development.
> chandler is a struggling project that hasn't produced a finished product in six years. I believe that's demonstrably false as there are thousands of daily users, including a number of entire organizations. If your only criteria of a "finished product" is whether it has a version number greater than 1.0, it shouldn't be hard to find other ebuilds that fail that criteria too. > the founder just left. May I point out that Gentoo's founder also left? People leaving a project is not a definitive sign of anything. > i'm uncomfortable to add a project that is the subject of a book on failed software development. I would only ask that you judge the software based on the software, not on books or blogs. Consider bouncing Chandler because it's big, has too many library dependencies (wxpython, pylucene, etc), the build system generates extra copies of dependencies, no Gentoo maintainer has stepped forward, or other technical concern, not because you read a book. (Or did you actually read that book? The book was about the difficulty of figuring out what to build, ie product management, not failed software development itself). No, Chandler has not lived up to the hype. But hype is not a rational way to judge software.
(In reply to comment #21) > > chandler is a struggling project that hasn't produced a finished product in six years. > > I believe that's demonstrably false as there are thousands of daily users, > including a number of entire organizations. If your only criteria of a > "finished product" is whether it has a version number greater than 1.0, it > shouldn't be hard to find other ebuilds that fail that criteria too. sorry, i was under the impression it was still in alpha. > > the founder just left. > > May I point out that Gentoo's founder also left? People leaving a project is > not a definitive sign of anything. heh, good point. > > i'm uncomfortable to add a project that is the subject of a book on failed software development. > > I would only ask that you judge the software based on the software, not on > books or blogs. Consider bouncing Chandler because it's big, has too many > library dependencies (wxpython, pylucene, etc), the build system generates > extra copies of dependencies, no Gentoo maintainer has stepped forward, or > other technical concern, not because you read a book. (Or did you actually > read that book? The book was about the difficulty of figuring out what to > build, ie product management, not failed software development itself). i did read it. it makes me wary. i'm sorry. > No, Chandler has not lived up to the hype. But hype is not a rational way to > judge software. this is true. i'll have a look at what would be needed to move this forward.
this is more involved than i thought. the java bits i'll need help with. the server bits i'll need help with. but i can start on the desktop client parts. if i figure out what those parts are... the toolchain gcj mungding looks insteresting. i'll have to look how big a mess that will be.
> i'll have a look at what would be needed to move this forward. That would be great. I'm using the 0.7.7 release under Windoze at work, and on gentoo at home, I'm using the 0.7.7 Ubuntu build that's available here (which is working fine on my AMD64 arch, for some reason): http://downloads.osafoundation.org/chandler/releases/0.7.7/#enduserlinux I'm syncing them both to a "hub" server account. This also gives you nice AJAX-y web-based access to your tasks/calendar. It's quite a nice app that really does a better job than sunbird/lightning, kontact, evolution, and most groupware and project management apps, for my needs. Haven't had any reliability issues at this time, I will bang on it more. The existing overlay notes here are about a year old: http://chandlerproject.org/Developers/GentooBuildNotes
Just discovered chandler, it looks like a great project - just what I've been searching for. I'm willing to help maintain the e-build, though it would be my first time doing so. I'll have to play around with what's here.
I started to work on the ebuild provided in this bug, and bring it up to Chandler's current version, 1.0.2 But upstream build system is somewhat unconventional. Patched versions of external dependencies are kept with in svn tree. Seperating dependencies is a lot of hard work and would involve patching upstream build system. A deb package exists here http://svn.osafoundation.org/sandbox/packaging/deb/chandler/trunk/debian/ PyLucene is one of the many dependencies, which do not have ebuilds in the tree yet. http://bugs.gentoo.org/show_bug.cgi?id=81416
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 181466 [details] A new (untested) chandler ebuild with some modifications to update it. I'm working to get a Chandler 1.0.2 ebuild working. I thought some of my efforts would be good to document here. License is Apache-2.0 not GPL. Fixed. The download location has changed. Fixed. According to https://bugzilla.osafoundation.org/show_bug.cgi?id=1514 GCJ_HOME is no longer needed (in fact if you grep GCJ_HOME in the chandler source there's one reference in one shell script that simply echoes it.) Thus, I removed the GCJ_HOME related lines from the ebuild. The following are dependencies (not sure if runtime or buildtime): (sorry for the cryptic way I noted them. Maybe it'll be useful to someone. # dependencies in external/ to be included in [R]DEPEND as needed # C-= Chandler-version, or the version included in the Chandler tree # Cpatch= Chandler has patched the thing # Cnopatch= Chandler has not patched it (hooray) # # config -> no dep required # configobj -> C-4.3.2 (dev-python/configobj-4.5.3 ~x86) Cnopatch # dateutil -> C-1.1 (dev-python/python-dateutil-1.1) # Cpatch to stop iteration after 20 years # db -> only rebuilt on windows no dep needed (sys-libs/db-4.5.20_p2-r1 in system) # docutils -> C-0.4 (in system no dep required) Cnopatch # eggtranslations -> C-1.1-r10-2 (OSAF product not in portage tree) # epydoc -> C-3.0beta1 (dev-python/epydoc-2.1-r2 x86 # dev-python/epydoc-3.0.1 ~x86) Cpatch adds --exclude feature - Needs upstream # icu -> C-3.6 (dev-libs/icu-3.8.1-r1 x86) Cnopatch # m2crypto -> C-0.18.2 (dev-python/m2crypto-0.16 x86 # dev-python/m2crypto-0.18.2 ~x86) Cnopatch # already depends on epydoc when with doc useflag. Perhaps Chandler doesn't # need it but m2crypto does. # openjdk -> C-openjdk-7-ea-j2re-b21-Linux (not in portage tree but sun-jre is) Cnopatch # C-openjdk-7-ea-j2sdk-b21-Linux (not in portage tree but sun-jdk is) Cnopatch # C-apache-ant-1.7.0-bin (dev-java/ant-1.7.1 x86) Cnopatch # includes openjdk and apache-ant (only as "repackage[d] full binaries") # openssl -> C-0.9.8d (dev-libs/openssl-0.9.8 x86 in system) Cpatch to build on windows # parsedatetime -> C-0.8.6 (not in portage tree) Cnopatch # PyICU -> C-0.8-92 (not in portage tree) Cpatch for cygwin # pylint -> C-? (dev-python/pyling-0.13.1 x86) Cnopatch # C-logilab-astng-0.17.0 (dev-python/astng-0.17.0 x86) Cnopatch # C-logilab-common-0.21.2 (dev-python/logilab-common-0.21.2 x86) Cnopatch # PyLucene C-2.3.1-3-418 (OSAF product not in portage tree yet Bug#) # python C-2.5.1 (dev-lang/pytho-2.5.2-r7 x86 in system) Cnopatch # C-bzip2-1.0.3 (app-arch/bzip2-1.0.5-r1 x86) Cnopatch # readline C-5.2 only rebuilt on windows and darwin (in system) # setuptools C-0.6c6 (dev-python/setuptools-0.6_rc8-r1 x86 in system) Cnopatch # swig C-1.3.29 (dev-lang/swig-1.3.36 x86) Cpatch something to remove wx prefix? # twisted C-r18795 (dev-python/twisted-8.1.0) Cpatch to preserve IMAP4Client capability API # vobject C-0.7.0-r206-1 (dev-python/vobject-0.7.1 ~x86) Cnopatch # wx C-wxPython-r218 (dev-python/wxpython-2.8.9.1-r2 x86) Cnopatch # zanshin C-171 (OSAF product not in portage tree) # zope C-3.3.0b2-r71371 (net-zope/zope-2.10.7 x86 # net-zope/zope-3.3.1 ~x86) Cnopatch
Created attachment 207007 [details] chandler-1.0.3.ebuild I tried to update Jacob's ebuild to version 1.0.3 of Chandler. I ran into (at least) two stoppers that prevent a successful build, at least on amd64: https://bugzilla.osafoundation.org/show_bug.cgi?id=12900 and https://bugzilla.osafoundation.org/show_bug.cgi?id=12901 Both are in connection with the automated downloads performed during the make process. One is fixed by the makefile patch which I'll attach in a minute. For the second, I don't have an automated fix yet, but it can be circumvented manually. In the end, IMHO they should both be fixed upstream by providing the correct files for download on the project server... Anyhow, even though this ebuild is not fully functional, it might help the next poor girl who wants to put some effort in this area. In comparison to the 1.0.2 ebuild, quite a number of fixme's are removed, e.g. by using EAPI 2 (that's why the gcj dependency didn't work), added support for debug builds, and fixed URLs...
Created attachment 207008 [details] zope.interface.patch
Yo mephinet. I'gonna let you finish, but my patch really fixes the whole zope.interface url problems. It seems you missed one part of the Makefile that tries to download zope.interface. Im attaching an addendum to your patch that got me past that. Its more a quick and dirty thing, but it does work. I also needed to remove the gdata plugin in the Makefile for chandler to finally compile. But that was more due to that fact that i didn't find where chandler storing the url for the gdata.py thingy. It doesnt really matter though as chandler didn't get really far when I tried starting it. So the gdata plugin isn't our biggest problem right now.
Created attachment 211825 [details, diff] more patches for the zope.interface dowload not referenced in the ebuild, add it to the old patch and redigest
I am having trouble getting Chandler 1.03 to compile on x86-64. First, I get the following error: /var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/icu/icu-3.6/icu/source/layoutex/ParagraphLayout.cpp:801:6: error: #elif with no expression Turns out that empty #elif declarations are no longer valid in gcc 4.4, and will throw the above error (http://gcc.gnu.org/gcc-4.4/porting_to.html). Downgrading to a version of gcc prior to 4.4 fixes this issue. But, after downgrading gcc, I still can not get Chandler to build. Now I am getting the following error: CFLAGS="-march=core2 -O2 -pipe" /var/tmp/portage/app-office/chandler-1.0.3/work/ chandler-1.0.3/external/release/bin/python -m jcc --jar lucene-java-2.3.1/build/ lucene-core-2.3.1.jar --jar lucene-java-2.3.1/build/contrib/snowball/lucene-snow ball-2.3.1.jar --jar lucene-java-2.3.1/build/contrib/highlighter/lucene-highligh ter-2.3.1.jar --jar lucene-java-2.3.1/build/contrib/analyzers/lucene-analyzers-2 .3.1.jar --jar lucene-java-2.3.1/build/contrib/regex/lucene-regex-2.3.1.jar --ja r lucene-java-2.3.1/build/contrib/queries/lucene-queries-2.3.1.jar --jar build/j ar/extensions.jar --package java.lang java.lang.System java.lang.Runtime --packa ge java.util java.text.SimpleDateFormat --package java.io java.io.StringReader j ava.io.InputStreamReader java.io.FileInputStream --exclude org.apache.lucene.que ryParser.Token --exclude org.apache.lucene.queryParser.TokenMgrError --exclude o rg.apache.lucene.queryParser.QueryParserTokenManager --exclude org.apache.lucene .queryParser.ParseException --python lucene --mapping org.apache.lucene.document .Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Prope rties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence org.apache .lucene.search.Hits 'length:()I' 'doc:(I)Lorg/apache/lucene/document/Document;' --version 2.3.1 --files 2 --build Traceback (most recent call last): File "/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/ release/lib/python2.5/runpy.py", line 95, in run_module filename, loader, alter_sys) File "/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/release/lib/python2.5/runpy.py", line 52, in _run_module_code mod_name, mod_fname, mod_loader) File "/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/release/lib/python2.5/runpy.py", line 32, in _run_code exec code in run_globals File "/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/release/lib/python2.5/site-packages/JCC-1.8-py2.5-linux-x86_64.egg/jcc/__init__.py", line 27, in <module> from jcc import cpp File "/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/release/lib/python2.5/site-packages/JCC-1.8-py2.5-linux-x86_64.egg/jcc/__init__.py", line 30, in <module> from _jcc import initVM ImportError: /var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/release/lib/python2.5/site-packages/JCC-1.8-py2.5-linux-x86_64.egg/jcc/_jcc.so: undefined symbol: JNI_GetDefaultJavaVMInitArgs make[2]: *** [compile] Error 255 make[2]: Leaving directory `/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/PyLucene/PyLucene-2.3.1-3-418' make[1]: *** [build] Error 2 make[1]: Leaving directory `/var/tmp/portage/app-office/chandler-1.0.3/work/chandler-1.0.3/external/PyLucene' make: *** [PyLucene] Error 2 Here is my emerge --info: Portage 2.1.8.3 (default/linux/amd64/10.0/desktop, gcc-4.4.3, glibc-2.11.2-r0, 2.6.34-gentoo-r2 x86_64) ================================================================= System uname: Linux-2.6.34-gentoo-r2-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T7250_@_2.00GHz-with-gentoo-1.12.13 Timestamp of tree: Tue, 24 Aug 2010 14:45:04 +0000 app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4, 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="-march=core2 -O2 -pipe" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3"
upstream is pretty much dead, afaik.
Can someone with bug edit powers close this? Chandler product has been fully dead for a decade.
