It would be nice if we could get the latest stable upstream version of bugzilla (3.2) in a prepackaged RPM.
Created attachment 329847 [details] initial spec file diff with modifications to succesfully build new rpm files. i haven't even tried installing the resultant rpms yet, let alone test the bugzilla instance that's created, but it's a start.
hmm. it seems to think it now depends on perl(Authen::Radius), perl(DBD::Oracle) and perl(sanitycheck.cgi).
Created attachment 329859 [details] spec diff with extra perl requirements excluded okay. this one installs (well, updates) on my F9 i386 system. be warned - the post script runs checksetup (i think) which converts some tables to InnoDB .. which can take a while.
"it's working! it's working!!" so far, at least. :-)
Created attachment 329979 [details] spec diff with a bit more tidying up and commenting. just a small update - mostly comments. can someone advise what should happen next please? cheers.
Created attachment 331602 [details] more tidying and 3.2.2 exciting new spec for 3.2.2! got a bit carried away with the Requires - removed lots including smtpdaemon (you don't _have_ to have bugmail) and mod_perl. opinions very welcome on that. relevant security advisories: "Local files on the server can be attached to a bug (making them publicly visible) when importing bugs with --attach_path Unprivileged users can approve/unapprove all quips It was possible for users to upload a malicious attachment to that would run in the context of Bugzilla's domain (thus circumventing cross-site request protections in browsers). Bug updating was vulnerable to a cross-site request forgery. Note that this issue was only fixed for 3.2.1 and 3.3.2 even though all versions of Bugzilla are affected (see below for an explanation). Keywords, unused flag types, and saved searches could be deleted via cross-site request forgery. Also, a user's preferences could be changed via cross-site request forgery."
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Created attachment 332429 [details] updated rw-paths patch file just re-tested the new spec and the rw-paths.patch fails to apply. (one of the comments just after the changed lines is messing up the patch context) here's the updated patch.
*** Bug 484206 has been marked as a duplicate of this bug. ***
*** Bug 466077 has been marked as a duplicate of this bug. ***
*** Bug 484758 has been marked as a duplicate of this bug. ***
hello guy's I have submited 3.0.8 into F-11 , F-10 and F-9 and now I have plans to upgrade to 3.2.2 into rawhide, everyone agree with this ?
+1 for move to 3.2 in rawhide, as this version of Bugzilla removes the use of table locking for MySQL. I'm also happy to see this package maintained again.
Itamar - big thanks for picking this up! will 3.2.2 also appear in F10? i'd like it to if possible.
(In reply to comment #14) please take a look http://koji.fedoraproject.org/koji/taskinfo?taskID=1222760 big thanks for your patches, why you don't join fedora project and help making bugzilla rpm package better ?
(In reply to comment #15) aw, cool! :-) just a few thoughts... 1) from the build log: Processing files: bugzilla-contrib-3.2.2-1.fc11-noarch /usr/lib/rpm/pythondeps.sh: line 8: python: command not found do we need a BuildRequires on python for the contrib package? 2) why is mod_perl in the Requires? afaiui it will only make things quicker, it's not actually required to make things work. that's why i mentioned it in the updated %description. if you want to keep it in the Requires then can you remove it from the %description? 3) with the customized __perl_requires only excluding those four things you pick up lots of supposedly optional perl requirements. that's why i modified the wrapper script to ignore everything. i'd argue it's also a lot easier to maintain this way - you just check the release notes and put perl(Foo) in the Requires for each thing they list there. i realise that's not automatic but the many optional features are messing with that, and that's unlikely to change any time soon. 4) according to https://fedoraproject.org/wiki/Packaging/Perl#Perl_Requires_and_Provides we should be using the perl(Foo) style in Requires. so if you do keep things as they are i guess you ought to change perl-SOAP-Lite to perl(SOAP::Lite) but, again, that's really (according to the release notes) an optional component. hope that's helpful. thanks for asking about joining the fedora project - i'm drifting slowly in that direction but at the moment i'm concentrating my effort on encouraging my government to do the same. :-)
> 1) from the build log: > do we need a BuildRequires on python for the contrib package? --> done > 2) why is mod_perl in the Requires? afaiui it will only make things quicker, > it's not actually required to make things work. --> mod_perl is recommended way to run bugzilla in apache. > that's why i mentioned it in the updated %description. if you want to keep it > in the Requires then can you remove it from the %description? --> done > 3) with the customized __perl_requires only excluding those four things you > pick up lots of supposedly optional perl requirements. that's why i modified > the wrapper script to ignore everything. > i'd argue it's also a lot easier to maintain this way - you just check the > release notes and put perl(Foo) in the Requires for each thing they list there. > i realise that's not automatic but the many optional features are messing with > that, and that's unlikely to change any time soon. --> I will let it in the current way, the optional perl modules is not too BIG, but I think about your suggestion in the future > 4) according to > https://fedoraproject.org/wiki/Packaging/Perl#Perl_Requires_and_Provides we > should be using the perl(Foo) style in Requires. so if you do keep things as > they are i guess you ought to change perl-SOAP-Lite to perl(SOAP::Lite) but, > again, that's really (according to the release notes) an optional component. --> done > hope that's helpful. thanks for asking about joining the fedora project - i'm > drifting slowly in that direction but at the moment i'm concentrating my effort > on encouraging my government to do the same. :-) --> this is the future, for government is recommended to know what the software is doing, and this is not possible with a closed source program thanks :-)
excellent - that's great! can i just ask again though, from my comment #14: if the rawhide/f11 build works okay will we also get an f10 build so we don't have to wait more months (and upgrade fedora) to get 3.2?
ok
bugzilla-3.2.2-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/bugzilla-3.2.2-2.fc9
bugzilla-3.2.2-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/bugzilla-3.2.2-2.fc10
bugzilla-3.2.2-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update bugzilla'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2417
bugzilla-3.2.2-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update bugzilla'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2418
fantastic! i'll install and play tomorrow. :-D
(In reply to comment #24) > fantastic! i'll install and play tomorrow. :-D make a backup first :-) and go ahead.
bugzilla-3.2.2-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
bugzilla-3.2.2-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.