It's a load of crap that gentoo can't be used on a server ;) Would you please, please add bugzilla ebuild or at least Bundle::Bugzilla perl module from CPAN so I can get debugging rather than reading my email... Reproducible: Always Steps to Reproduce:
Created attachment 7899 [details] Ebuilds for bugzilla I've attached the ebuilds I've created this week-end (see http://forums.gentoo.org/viewtopic.php?t=33253). It contains the following ebuilds : - dev-perl/Data-Dumper - dev-perl/Template-Toolkit - dev-perl/File-spec - dev-perl/Text-Tabs+Wrap - net-misc/bugzilla The first two are broken but I can't find what the problem is (I'm not a Perl developper :( ).
Since you are one of the resident perl gods ;-) Cheers - //zhen
It seems I was not alone on this one. And mcummings, I'll come and bow you again if you make this work. :D And thanks Laurent Maestracci for the ebuilds. :)
zhen, i think the actual package is more appropriate than the perl module ...
Created attachment 7956 [details] bugzilla-2.16.2.ebuild update I've updated the bugzilla ebuild The *.cgi/*.pl scripts needed /usr/bonsaitools/bin/perl instead of /usr/bin/perl Still can't test it since the Template-Toolkit ebuild doesn't work for me as you can see below. Another point is Data-Dumper. The ebuild doesn't work but it seems already installed (perl 5.8 includes it ?) Installing optional components into /usr/local/tt2 + docs ACCESS DENIED mkdir: /usr/local/tt2 mkdir /usr/local/tt2: Permission denied at bin/tt2inst line 55 make: *** [tt2_install] Error 255 !!! ERROR: dev-perl/Template-Toolkit-2.08 failed. !!! Function perl-module_src_install, Line 72, Exitcode 2 !!! (no error message) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-Template-Toolkit-2.08-7437.log" mkdir: /usr/local/tt2 --------------------------------------------------------------------------------
Created attachment 7957 [details] bugzilla-2.16.2.ebuild update I've updated the bugzilla ebuild The *.cgi/*.pl scripts needed /usr/bonsaitools/bin/perl instead of /usr/bin/perl Still can't test it since the Template-Toolkit ebuild doesn't work for me as you can see below. Another point is Data-Dumper. The ebuild doesn't work but it seems already installed (perl 5.8 includes it ?) Installing optional components into /usr/local/tt2 + docs ACCESS DENIED mkdir: /usr/local/tt2 mkdir /usr/local/tt2: Permission denied at bin/tt2inst line 55 make: *** [tt2_install] Error 255 !!! ERROR: dev-perl/Template-Toolkit-2.08 failed. !!! Function perl-module_src_install, Line 72, Exitcode 2 !!! (no error message) --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-Template-Toolkit-2.08-7437.log" mkdir: /usr/local/tt2 --------------------------------------------------------------------------------
is there any way to install Template-Toolkit? It seems that the default answer for installation path [/usr/local/tt2] is wrong, but what is the right answer?
Created attachment 8444 [details] bugzilla-2.17.3.ebuild The sandbox violation problem of Template-Toolkit has been solved by: # (export SANDBOX_DISABLED=1 ; emerge dev-perl/Template-Toolkit) There was another problem: ebuild used "doins", which doesn't work recursivley. I've used "cp -r" instead. Additionally, I've decided to try Bugzilla-2.17.3. In my case it also required to upgrade to dev-perl/CGI-2.88 Everything has been installed (ignoring the annoying fact of installing Template-Toolkit interactively) and works fine. I attach my version of ebuild.
I have heard that portage will soon integrate automatic cpan usage, so I am marking this as invalid, but it will still be in the database.
Created attachment 8785 [details] improved installation and postinstallation bugzilla-2.17.3-r1.ebuild: installation and post-installation has been touched a lot to work smooth and friendly. Perhaps same thing I should do for un-installation: now you should drop bugs db manually. Well, two things should stay manual for sure (as they closely relates to another package - apache): apache crontab and /etc/apache/conf/apache.conf. By the way, bugzilla-2.17.3.ebuild (previous one) has been used in production for a couple of weeks and works stable. Why not commit it to the portage?
Created attachment 8786 [details] improved installation and postinstallation bugzilla-2.17.3-r1.ebuild: installation and post-installation has been touched a lot to work smooth and friendly. Perhaps same thing I should do for un-installation: now you should drop bugs db manually. Well, two things should stay manual for sure (as they closely relates to another package - apache): apache crontab and /etc/apache/conf/apache.conf. By the way, bugzilla-2.17.3.ebuild (previous one) has been used in production for a couple of weeks and works stable. Why not commit it to the portage?
Created attachment 8787 [details] improved installation and postinstallation bugzilla-2.17.3-r1.ebuild: installation and post-installation has been touched a lot to work smooth and friendly. Perhaps same thing I should do for un-installation: now you should drop bugs db manually. Well, two things should stay manual for sure (as they closely relates to another package - apache): apache crontab and /etc/apache/conf/apache.conf. By the way, bugzilla-2.17.3.ebuild (previous one) has been used in production for a couple of weeks and works stable. Why not commit it to the portage?
Created attachment 8788 [details] improved installation and postinstallation bugzilla-2.17.3-r1.ebuild: installation and post-installation has been touched a lot to work smooth and friendly. Perhaps same thing I should do for un-installation: now you should drop bugs db manually. Well, two things should stay manual for sure (as they closely relates to another package - apache): apache crontab and /etc/apache/conf/apache.conf. By the way, bugzilla-2.17.3.ebuild (previous one) has been used in production for a couple of weeks and works stable. Why not commit it to the portage?
Oh, man, I've got "Status: 400 Bad request (malformed multipart POST)" and tried to fix it. Several times as you can see. My appologize. Seems, bugzilla on Gentoo has a bug: it doesn't work well with tgz attachments: it shows error message on a submit, but it submits on backend.
The bugzilla ebuilds are still not in the portage tree. IMHO this bug should be reopened...
the actual ebuild for bugzilla is attached, but not added to portage.
*** Bug 17709 has been marked as a duplicate of this bug. ***
Looks like we need ebuilds for some of the perl modules that it wants to install. Any takers?
Created attachment 11371 [details] Ebuild for bugzilla with perl modules All of the perl ebuilds are from the original submission.
please change >=sys-devel/perl-5.005 to >=dev-lang/perl-5.005 in the DEPEND statement of bugzilla-2.7.3-r1.ebuild in order to work.
great job ! all goes well until the last step ebuild /var/db/pkg/net-misc/bugzilla-2.17.3-r1/bugzilla-2.17.3-r1.ebuild config I get this : !!! ERROR: net-misc/bugzilla-2.17.3-r1 failed. !!! Function pkg_config, Line 94, Exitcode 1 !!! (no error message) I executed the end of the pkg_config function by copying each interesting line to an xterm. The only last problem is I needed to 'chown -R apache:apache /home/httpd/bugzilla' to get access to bugzilla
I just installed this based on the 2003-05-01 ebuild, and thought I'd add my comments to this thread.... I'm using apache2 (2.0.47) so perhaps some of my configuration differences are due to that. - moved bugzilla.conf from /etc/apache/conf to /etc/apache2/conf - added LOCK TABLES privilege to bugs user, didn't seem to want to work without that - "su - apache -c ..." commands didn't work for me (perhaps since apache's shell is /bin/false?), so I did those as root, and then had to chown -r apache:apache again later on I'm not sure why the admin email/password/name prompts are commented out.... I ended up hard-coding them in bz.cfg.templ. Otherwise, though, it's all happy and working.
wrong category
Created attachment 17803 [details] Updated bugzilla Updated ebuild to match new portage, edited config part of ebuild to complete sucessfully, added an extra chown -R apache:apache /home/httpd/bugzilla because when running one of the bugzilla scripts, it changes ownership. Also moved to net-www instead of net-misc. Removed the additional perl modules which were already in the portage tree. Further testing and then we'll put it in the portage tree.
Created attachment 17804 [details] Updated bugzilla Updated ebuild to match new portage, edited config part of ebuild to complete sucessfully, added an extra chown -R apache:apache /home/httpd/bugzilla because when running one of the bugzilla scripts, it changes ownership. Also moved to net-www instead of net-misc. Removed the additional perl modules which were already in the portage tree. Further testing and then we'll put it in the portage tree.
Should be fixed to use the correct apache directory (/etc/apache2 if you don't have apache-1).
The config should also handle the case when mysql is not running on localhost.
*** Bug 29578 has been marked as a duplicate of this bug. ***
bugzilla ebuild is borked, working on....
Hi, The web-apps herd is currently working on delivering some important changes to the way that web-based applications are installed and managed on Gentoo Linux. Until this work is complete, we're not commiting ebuilds for new web-based packages. I've marked this bug as 'LATER'. As soon as we are able to, we will come back to this bug and help you convert your ebuild to our new approach. Keep at it - a working bugzilla ebuild is sure to be popular! Many thanks for your patience, Stu
*** Bug 32164 has been marked as a duplicate of this bug. ***
Hi Stuart, Is it possible to reopen this bug yet? From what I can see on my installation the Apache guys have done there magic and reorganised the apache install. If I'm wrong with this is there an open bug for the apache changes that we can make this bug depend on?
reopening as requested
I do have an ebuild ready for this, the biggest problem that I'm having are upgrades... the upgrades for bugzilla are NEVER easy... I will finish up what I can and let it be up to the admin to upgrade.
Commited bugzilla ebuild as unstable, the ebuild works fine but there is no safe way to upgrade - Maybe someone could research this for me but in any case bugzilla.org says to backup before upgrading due to possible problems with the bugzilla database.
