Chiliproject is a community fork of Redmine. I would like to use it instead of Redmine, but there is no ebuild yet. I had problems creating an ebuild myself as I'm not experienced with ruby and its dependencies. http://www.chiliproject.org
Created attachment 280149 [details] chiliproject ebuild - installs in image - not tested using emerge This is what I have till now. There are no errors using "ebuild <my_ebuild> install". I didn't test it using emerge, yet.
Created attachment 280151 [details] files needed for ebuild
Created attachment 280263 [details] chiliproject ebuild - still work in progress New version after some work work and investigation. You need to run bundler install for chiliproject to work. Running it in the ebuild didn't work. I'm trying this now under postinst. Another idea would be a simple message for the user, that he has to run it. ebuild works for me with use flags git,mysql,startdate, when running bundler manually. Couldn't test running bundler in postinst, yet. My idea is installing the dependencies using portage and hoping, that bundler uses them instead of installing own versions. This works partially at the moment. startdate is my custom use flag for installing the startdate redmine patch: http://www.redmine.org/issues/3035
Created attachment 280265 [details] files needed for ebuild
Comment on attachment 280151 [details] files needed for ebuild Obsoleted by last attachment.
Created attachment 288195 [details] chiliproject-2.2.0.ebuild Version bump to current 2.2.0 Made it EAPI=4 comliant. Fixed some bugs.
Created attachment 302351 [details] chiliproject-3.0.0.ebuild
Comment on attachment 302351 [details] chiliproject-3.0.0.ebuild version bump + small fixes
Created attachment 302353 [details] files needed for ebuild Updated files in FILESDIR
Created attachment 308379 [details] chiliproject-3.1.0.ebuild Version bump. Updated files archive follows.
Created attachment 308381 [details] files needed for ebuild Current FILESDIR for the ebuild(s). As I'm a bit lazy about updating this bug: The ebuilds for this are available in my overlay, too: http://groeper-berlin.de/Gentoo/overlay.xml Here is a small tutorial how to use it: http://groeper-berlin.de/Gentoo/
the redefinition of ${S} is missing a "chiliproject-3.1.0" after the "... all/" After I added that to the ebuild it built as expected. Still need to set everything up and test, but it is starting to look OK.
(In reply to comment #12) > the redefinition of ${S} is missing a "chiliproject-3.1.0" after the "... > all/" After I added that to the ebuild it built as expected. > > Still need to set everything up and test, but it is starting to look OK. Could it be, that your temporary portage dir is not "/var/tmp/portage"? This is my current redefinition of ${S}: S=$WORKDIR/all/`ls /var/tmp/portage/www-apps/chiliproject-${PV}/work/all/` For chiliproject-3.1.0 the directory below "work/all" is chiliproject-chiliproject-d61ad01 here. This name is referencing the git commit, which is tagged as Version 3.1.0. For not having to update that on each version bump I use this ls-trick. I'm confused why this directory should be named "chiliproject-3.1.0" on your system. But my method should work there, too. As long as the WORKDIR is the default one, I hardcoded. I'm wondering why I hardcoded this part of the path. I will fix that. Hopefully removing the hardcoded path will fix your issue. I'm running this ebuild one a few instances without problems.
Created attachment 309231 [details] chiliproject-3.1.0.ebuild Removed hardcoded path for WORKDIR in the ebuild. As this should really make no difference for everyone, that has successfully installed the ebuild, I didn't add a revision number. Not sure if this is an acceptable practice.
Created attachment 315099 [details] chiliproject-3.2.1.ebuild Version bump. Now using RUBY_S from ruby-ng.eclass instead of the aforementioned ls-trick to fix ${S} after download from github. Added ruby19 to USE_RUBY, because it is supported since chiliproject 2.0. But I'm not using ruby19 myself.
Created attachment 315201 [details] chiliproject-3.2.2.ebuild Version Bump. I want to stress, that this many releases are because chiliproject team is backporting current rails security bugs.
Created attachment 315903 [details] chiliproject-3.2.2-r1.ebuild The updated ebuild depends on dev-ruby/activesupport-2.3.14-r1, which fixes a problem with using bundler. Thanks go to Felix of the chiliproject team for showing me the proper solution for the problem: https://www.chiliproject.org/issues/529 My workaround using Gemfile.local is not needed anymore.
http://blog.chiliproject.org/releases/chiliproject-3-3-0-released/
Created attachment 322545 [details] chiliproject-3.3.0.ebuild
3.4.0 is released tried to version bump ebuild in my overlay, but didnt work, yet.
(In reply to comment #20) > tried to version bump ebuild in my overlay, but didnt work, yet. There is 3.4.0 in my overlay already. But a few minutes ago 3.5.0 was released. I'm working on this version bump. I will attach an updated ebuild here.
Sounds nice! :)) Where can I see your overlay? On http://gpo.zugaina.org/ is 3.3.0 in my overlay the most recent Looking forward to 3.5.0 :)
(In reply to comment #22) > Sounds nice! :)) > Where can I see your overlay? See Comment #11
Created attachment 334948 [details] chiliproject-3.5.0.ebuild Version bump to 3.5.0. There is a problem running bundle install, because of the rails update, that results in: > You have requested: > rails = 2.3.15 > > The bundle currently has rails locked at 2.3.14. > Try running `bundle update rails` This can be resolved by going to the chiliproject directory (normally /var/lib/chiliproject) deleting (or moving) Gemfile.lock and then running bundle install again (bundle install call matching to your USE flags is shown in elog messages). I don't have a good solution for this yet. Simply running bundle update would ignore changes to the USE flags and automatically removing Gemfile.lock doesn't sound like a good solution either.
I am getting a: emerge: there are no ebuilds to satisfy "~dev-ruby/rails-2.3.15:2.3[ruby_targets_ruby18]". (dependency required by "www-apps/chiliproject-3.5.0[-test,ruby_targets_ruby18]" [ebuild]) I am not using your overlay. Do I need a special rails euild?
(In reply to comment #25) > emerge: there are no ebuilds to satisfy > "~dev-ruby/rails-2.3.15:2.3[ruby_targets_ruby18]". > (dependency required by > "www-apps/chiliproject-3.5.0[-test,ruby_targets_ruby18]" [ebuild]) > > I am not using your overlay. > Do I need a special rails euild? emerge --sync should help. rails-2.3.15 was released yesterday.
:))
dispatch-conf messed up my /etc/init.d/chiliproject changed chiliproject user and group to redmine and reverted redmine-dir from /var/lib/chiliproject to /var/lib/redmine. The result was: git chiliproject # /etc/init.d/chiliproject restart * Starting redmine ... * WARNING: -c/--chuid is deprecated and will be removed in the future, please use -u/--user instead /usr/bin/ruby: No such file or directory -- /var/lib/redmine/script/server (LoadError) * start-stop-daemon: failed to start `/usr/bin/ruby' reverted back manually and server is starting fine.
Created attachment 335052 [details] files needed for ebuild (In reply to comment #28) > dispatch-conf messed up my /etc/init.d/chiliproject > > changed chiliproject user and group to redmine and reverted redmine-dir from > /var/lib/chiliproject to /var/lib/redmine. Sorry for that. That's the pitty with holding this bug report up-to-date. I forgot to update the archive containing the files directory. In my overlay this was fixed months ago. I used this as a chance to tidy up the files directory (and fix chiliproject.confd) before uploading this new tarball.
Created attachment 337848 [details] chiliproject-3.6.0.ebuild.diff Version Bump with support for most recent rails!
Created attachment 337856 [details] chiliproject-3.6.0.ebuild I made some more changes than chiliproject-3.6.0.ebuild.diff does. Just want to repeat. If you can't find the current version here, have a look at my overlay.
Created attachment 338750 [details] chiliproject-3.6.0-r1.ebuild Intermediate security update. chiliproject-3.6.0 ebuild depending on rails 2.3.17 and json 1.7.7. Use at your own risk (as usual). Officially chiliproject-3.6.0 uses rails 2.3.17. The chiliproject-3.6.0 ebuild depends on json 1.7.6, but chiliproject on its own would use the newer version, too. So if you want to wait for an official security update of chiliproject, you could fix the json issue by updating dev-ruby/json manually and running "bundle update" in /var/lib/chiliproject. After each update of chiliproject containing a rails version bump, you have to manually run "bundle update" at the moment. I didn't find a way to let the ebuild make the work for you, yet. Help would be appreciated.
Created attachment 338752 [details] files needed for ebuild Updated files to include patch needed for chiliproject-3.6.0-r1.ebuild
(In reply to comment #32) > Use at your own risk (as usual). Officially chiliproject-3.6.0 uses rails > 2.3.17. This should be: Officially chiliproject-3.6.0 uses rails 2.3.16.
Created attachment 338796 [details] chiliproject-3.7.0.ebuild version bump to 3.7.0 The official release contains more fixes than just using newer rails and json packages.
Created attachment 346046 [details] chiliproject-3.8.0.ebuild.diff
Thank you for great ebuild. I'd like to use it, but i'm getting error below... emerge -av www-apps/chiliproject These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy "<dev-ruby/i18n-0.5[ruby_targets_ruby18]". (dependency required by "www-apps/chiliproject-3.7.0::OverlayEnno[-test,ruby_targets_ruby18]" [ebuild]) (dependency required by "www-apps/chiliproject" [argument]) Could you please help me? Shouldn't it be requiring ">dev-ruby/i18n-0.5"? Thanks a lot, Jan
chiliproject depends on deprecated rails:2.3, which has been removed from the tree.
Oh, now i see. ...so it means, this ebuild is useless now? :( What a pity!
Currently, yes. You can retrieve the removed and required ebuilds from http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ But I'd recommend using redmine, that already supports rails:3.x
Ok, thank you a lot and have a nice day.
http://blog.chiliproject.org/community/announcing-end-chiliproject/
Upstream recommends using redmine and does not develop chiliproject any further.
