It would be appreciated if someone could build ebuilds for 'mason' and 'bricolage'. Mason: http://www.masonhq.com/ From the website Mason is a powerful Perl-based web site development and delivery engine. With Mason you can embed Perl code in your HTML and construct pages from shared, reusable components. Mason solves the common problems of site development: caching, debugging, templating, maintaining development and production sites, and more. Mason is 100% free and open source. Although it can be used from CGI or even stand-alone, it is optimally designed for use with two other open source technologies: mod_perl and Apache. Bricolage: http://www.bricolage.cc/index.html from the website Bricolage is a full-featured, open-source content-management and publishing system. Features include intuitive and highly configurable administration, workflow, permissions, templating, server-neutral output, distribution, and document management. Bricolage is written in Perl using HTML::Mason and Apache/mod_perl. Bricolage uses the PostgreSQL relational database to store content. Thank you for your consideration. Reproducible: Always Steps to Reproduce:
As added incentive to anyone willing to do these ebuilds. (I sure wish I knew enough to do them myself!) you may want to read this article: http://www.theregister.co.uk/content/31/30959.html It looks like one of our fav industry news rags "The Register" is converting to bricolage. :-)
Does Mason = dev-perl/HTML-Mason?
Yes it does. I did see the ER put in last week for Mason and another PERL module. I don't have the number off hand nor can I seem to find it using the query. I'm assuming that Mason was added as part of that request. :-)
The other ER was on 6/17 and was bug # 22996.
I guess what threw me off is that mason has been in the tree for a while now. I hope to get to this this weekend, sorry for the delay.
Not a problem. I could have sworn that I checked for mason before posting. I see that mason is in the tree so I guess I was fantasizing about checking for mason. Ahh heck. Stuff happens. You do a great job Mike. I'm not one of those that 'has to have it today' types. I was impressed enough with the reviews for bricolage that I'd like to try developing a web site in it. That's all. ;-)
=:) Moving the home office around this weekend, then I will be knocking out as many of these "enhancements" as I can. Should be a piece of cake, only 50 or so to go through ;0
Holy CREP. There has to be well over 50 some deps here. OK, maybe I was too generous with timelines. While I ponder this volume of deps, a few questions. * Does it work with any apache or only <2? * Same for mod_perl, though that would be affected by the above * Any hints on what a good cat would be for it? Consider this a poll for your take on it :)
I count 57 depends, 16 of which don't exist yet in portage. This may not get taken care of this weekend after all. I have a base ebuild locally, but would welcome any input (say, suggested ebuilds for the missing stuff ;) ).
Wow! I don't have any problem with you holding off on this. I realize what I had in mind is a bit beyond my current skill/knowledge set at the moment. Unless and until you reach a less busy spell, I think the community (of 1 as far as I know at the moment) can wait a bit. I'll make a good faith effort to look at the dependencies not in portage, though this is a new thing for me. Thanks for the heads up!
i know this sounds like a big project to tackle, and i'm afraid i don't know enough to help out, but this is something that i would like to test out also. it's been written about in recent issues of linux journal, so i would bet that others might have a newfound interest as well.
First, sorry for the delay - this ebuild has close to 60 dependancies (plus their dependancies, plus the deps of the deps of the deps...) so it took a while to get the time free to even think of tackling it. That said, all of the deps should be in the tree now. However, as noted withthe block to bug 37019, one issue still remains. Bricolage requires that mod_perl be statically compiled with apache-1*, which portage doesn't currently support. I've added the web-apps folks to this bug in the hopes that they have some insights (all I can think of is a kludged-apache that builds all of the mods_* in statically, and that probably wouldn't fly too well).
Created attachment 28276 [details] Ebuild in progress This is the ebuild I've been working on - should contain all of the deps as stated by the bricolage folks. Note that the license still needs to be fixed, not to menion getting a static mod-perl. It is *still* a work in progress - currently prompts for the location of your postgres control, for instance.
Bricolage 1.8.2 no longer requires mod_perl to be statically compiled. That ought to make things easier! Thanks for your great work, the Bricolage team and community appreciates it. :-D
Created attachment 42093 [details] bricolage ebuild I have ebuilds for the 2 perl deps not in the tree (MasonX-Interp-WithCallbacks Params-CallbackRequest) as well as for HTMLArea. The hang up right now is getting through the interactive setup part.
The installer in the trunk (for 1.10) can be made quiet. I'll look into having patches made against 1.8, but they will not be included in an official 1.8.x release.
Created attachment 44105 [details, diff] Quiet installation for 1.8.x This patch, backported from Bricolage's trunk (development for 1.10), will make the installer nearly silent when the INSTALL_VERBOSITY environment variable is set to QUIET (e.g. "INSTALL_VERBOSITY=QUIET make; make install"). It still asks for the postgres root password, and some of the defaults are wrong in Bricolage (e.g. uses nobody:nobody for Apache), so I assume another patch will be needed. HTH, thanks guys!
Mass re-assign.
1.9.0 (development for 1.10) has been released. It features a per-platform silent installation option, with approriate defaults for Gentoo already created. Hopefully no patches will be necessary. If you need anything changed, I can commit it.
1.10.0 has been released and can be installed without user input. To trigger the silent install: # make INSTALL_VERBOSITY=QUIET USE_DEFAULTS=gentoo # make install If any of the defaults (see inst/defaults/gentoo) are wrong, let me know and I'll apply any patches for 1.10.1.
This is a bit embarrassing, but I'd actually forgotten we had this tucked away under perl-requests. Looking now - i guess my first task is tracking down all of the deps again (looks htmlarea is no longer in the tree...swear i'd put it in at one point...). will keep you all posted, ~mcummings
ok, my status so far is that there are about a half dozen perl deps that have been added since this first hit bugzilla, plus i can't find a valid/active copy of htmlarea, and the alternative isn't stable enough yet (doesn't even have a stable release), so that optional functionality won't be present. other than that - working on it still :)
(In reply to comment #22) > i can't find a valid/active copy of htmlarea, and the alternative isn't stable > enough yet (doesn't even have a stable release), so that optional functionality > won't be present. other than that - working on it still :) HTMLArea is dead. Xinha is a fork, so it's probably about as stable, if not more, even though it doesn't have an official "stable" release yet. But not being able to include it via an ebuild isn't a big deal since installing it is as easy as extracting a tarball in the right Bricolage directory, and we don't really encourage using WYSIWYG with Bricolage anyway.
(In reply to comment #23) > HTMLArea is dead. aye >Xinha is a fork, that's the one i couldn't remember the name of when i was typing :) (sounds like "Xena" didn't seem very professional) > as easy as extracting a tarball in the right Bricolage directory, and we don't > really encourage using WYSIWYG with Bricolage anyway. much appreciated since i've worked long and hard to avoid maintaining ebuilds that are only available via snapshots. back to filling missing deps for me :)
<update> Well, the good news (I guess) is that I have a 9k patch that brings DESTDIR support to bricolage, something sorely needed. The bad news is that either in bricolage itself, or somewhere in my patching (although I didn't specifically touch db related parts, still possible), the install process expects to su - to the postgres user and run some install/grants, which of course it can't in a sandbox (at least not natively). Does anyone know if it is possible to skip this step and let the user run this after the fact? (I'd hate to think I spent the whole day getting DESTDIR support in for nothing)
(In reply to comment #25) > Well, the good news (I guess) is that I have a 9k patch that brings DESTDIR > support to bricolage, something sorely needed. Cool! Can you email it to me and I'll see about getting it into the next release? > The bad news is that either in > bricolage itself, or somewhere in my patching (although I didn't specifically > touch db related parts, still possible), the install process expects to su - to > the postgres user and run some install/grants, which of course it can't in a > sandbox (at least not natively). That's not your fault. > Does anyone know if it is possible to skip > this step and let the user run this after the fact? (I'd hate to think I spent > the whole day getting DESTDIR support in for nothing) http://viewsvn.bricolage.cc/?rev=7154&view=rev In the next release (1.10.1), you will be able to do "make install_files" instead of "make install" to skip the database stuff. After the install, the user will need to run "make install_db". We're shooting for 1.10.1's release sometime later this week. Hopefully we can get all the necessary patches to make the ebuild work in before that.
(In reply to comment #26) > In the next release (1.10.1), you will be able to do "make install_files" > instead of "make install" to skip the database stuff. After the install, the > user will need to run "make install_db". 1.10.1 was released today. Hope that makes things easier.
sorry, got a bit swamped in real life, beginning to give this a whirl now.
http://dev.gentoo.org/~mcummings/overlay/ is now populated with an ebuild (and supporing perl modules) for a 90% working bricolage install. Still at large is getting the db updated (just haven't done it yet) and seeing it all work together. Believe it or not, I think this means the hard part is over with :)
(In reply to comment #29) > http://dev.gentoo.org/~mcummings/overlay/ is now populated with an ebuild (and > supporing perl modules) for a 90% working bricolage install. Still at large is > getting the db updated (just haven't done it yet) and seeing it all work > together. Believe it or not, I think this means the hard part is over with :) > Excellent, you rock. I noticed this in the ebuild: # The following required modules are either missing or out of date: # # Apache::Request I believe Apache::Request is installed by libapreq, which is already a dependency.
(In reply to comment #30) > > I noticed this in the ebuild: > > # The following required modules are either missing or out of date: > # > # Apache::Request > > I believe Apache::Request is installed by libapreq, which is already a > dependency. > yep on both accounts. at one point in my draft of this ebuild i had a list (commented) of all the perl deps, then took them out of the list one at a time. apache::request was just the last one left :)
My questions and suggestions appear during "my fight" with bricolage 1. IUSE. In INSTALL many optional depends so re-add with USE flag "bricolageplus" also CPAN tell me about too packges Bundle::Bricolage and Bundle::BricolagePlus example bricolageplus? ( >=dev-perl/Devel-Profiler-0.03 dev-perl/HTML-Template dev-perl/HTML-Template-Expr dev-perl/HTTP-DAV dev-perl/Net-FTPServer >=dev-perl/net-sftp-0.08 dev-perl/Pod-Simple >=dev-perl/Template-Toolkit-2.14 >=dev-perl/Test-Pod-0.95 dev-perl/XML-DOM ) 2. For required perl modules what not found in portage use "hack" modules recommended install by g-cpan (add ewarn before install) and depend write like (for future) ( >=dev-perl/Params-CallbackRequest-1.10 || >=perl-gcpan/Params-CallbackRequest-1.10 ) but here I find one problem with DEPEND :( example pkg_setup() { MODS="List-MoreUtils-0 MasonX-Interp-WithCallbacks-1.10 Params-CallbackRequest-1.10 Test-File-Contents-0.02 Test-MockModule-0.04 Term-ReadPassword-0 Text-Diff-HTML-0.02 Text-WordDiff" for MOD in $MODS; do if ! ( has_version ">=dev-perl/${MOD}" || has_version ">=perl-gcpan/${MOD}" ) ; then MODULE=`echo ${MOD} | sed 's/\-[0-9].\?[0-9]*$//g' -`; einfo "Please before install You need have g-cpan installed"; einfo "and run: g-cpan -i ${MODULE}"; einfo "Need version >= ${MOD}"; die; # I dont know how it change - DEPEND read only here :( # else # DEPEND="${DEPEND} || ( >=dev-perl/${MOD} >=perl-gcpan/${MOD} )"; fi done PLUS_MODS="Imager-0 PHP-Interpreter-0" if use bricolageplus; then for MOD in $PLUS_MODS; do if ! ( has_version ">=dev-perl/${MOD}" || has_version ">=perl-gcpan/${MOD}" ) ; then MODULE=`echo ${MOD} | sed 's/\-[0-9].\?[0-9]*$//g' -`; einfo "Please before install You need have g-cpan installed"; einfo "and run: g-cpan -i ${MODULE}"; einfo "Need version >= ${MOD}"; die; # else # DEPEND="${DEPEND} bricolageplus? ( || ( >=dev-perl/${MOD} >=perl-gcpan/${MOD} ) )"; fi done fi } 3. Need add "The Bricolage License" and use it ?! So, what you think about it ?
(In reply to comment #32) > 2. For required perl modules what not found in portage use "hack" > modules recommended install by g-cpan (add ewarn before install) > and depend write like (for future) <snip> g-cpan is not to be called from within a distributed ebuild. eof. > > 3. Need add "The Bricolage License" and use it ?! Last I checked license was just the Artistic license, no need for a special license. > So, what you think about it ? > Please see the overlay I posted in comment #29 > http://dev.gentoo.org/~mcummings/overlay/ Includes patches for bricolage to allow for DESTDIR and PREFIX calls. The only thing missing, that I just haven't had time to fix, is the setting up of the db. Otherwise it is a functional install.
(In reply to comment #33) > Please see the overlay I posted in comment #29 > > http://dev.gentoo.org/~mcummings/overlay/ > > Includes patches for bricolage to allow for DESTDIR and PREFIX calls. The only > thing missing, that I just haven't had time to fix, is the setting up of the > db. Otherwise it is a functional install. > Ok I'm try it Already need IUSE fix plz add "spell" flag to it and I suggest also add mod_gzip depend with "gzip" IUSE flag And what you think about USE flag "bricolageplus" idea ?
also I think in DEPEND need change dev-perl/Text-Aspell -> spell ? ( dev-perl/Text-Aspell ) becouse Text::Aspell as optional
DEPEND need changes (from INSTALL for 1.10) remove (not need anymore) dev-perl/HTTP-BrowserDetect added >=dev-perl/DateTime-0.21 dev-perl/DateTime-TimeZone dev-perl/Data-UUID
Testing on "x86" Install OK on "~x86" I have apache2 and cant testing After read "Bricolage (Manual Installation)" part from INSTALL I suggest In "src_unpack" MY_PV=${PV/_/} svn co http://svn.bricolage.cc/bricolage/tags/rel_${MY_PV}/sql ${S}/usr/local/bricolage/sql (required subversion with neon support added to DEPEND) In "pkg_config" run export conf/bricolage.conf settings bin/bric_pgimport -u postgres -p postgres -d ${DB_NAME} -c -m ${DBI_USER}:${DBI_PASS} <optional> change value MANUAL_APACHE(in conf/bricolage.conf) to "yes" run bin/bric_apachectl for generate apache config copy generated config from tmp/ to /etc/apache change MANUAL_APACHE value back to "no" </optional>
I have a working install now, minus the notes on how to add the db to postgres, but I'm not even sure its worth pursuing since the code bombs out under perl 5.8.8 because of constants being treated like array refs (and never being defined as such). bah.
(In reply to comment #38) > I have a working install now, minus the notes on how to add the db to postgres, > but I'm not even sure its worth pursuing since the code bombs out under perl > 5.8.8 because of constants being treated like array refs (and never being > defined as such). bah. On what version? Can you post or email me more details, so that we can perhaps get this fixed upstream?
Created attachment 95853 [details] ebuild
Created attachment 95854 [details, diff] configuration patch
This could also use some intervention from the webapp eclass, i just got too frustrated with it to pursue. I had to manually create the logs directory, repermission everything (in case anyone tries following my footsteps), and there is an unchecked dep on Apache::DB that you need to satisfy (silently fails to start, but debug explains why). I doubt that /usr/local/bricolage is the "gentoo way" to install this, but for now I didn't want to mess with it.
Re-assigning back to maintainer-wanted. I could never get this working without serious, serious patching, and even then not so much (NOTE: Patching was for installation, not because there's anything wrong with bricolage per se). But rather than have it sit in the perl@g.o queue and go lost, I'm pushing this back over to maintainer-wanted in case anyone comes along that can make it happen/happy.
WONTFIX for the reasons stated above.
