Description of problem: The 3.4 branch will become unmaintained once 4.2 is out (in rc2 now). Version-Release number of selected component (if applicable): 3.4.12 How reproducible: almost certain Steps to Reproduce: 1. use EPEL Bugzilla package 2. get security updates Actual results: not going to be available soon Expected results: available Additional info: 3.6 would be the minimum. 4.0 and 4.2 branches are/will be available also. Personally, I'm looking at EPEL6 until 2020, so I'd rather take the pain now of getting to 4.2, so we don't have another major branch rebase until the 4.2 branch goes unmaintained. I'm assuming nobody is going to volunteer to backport fixes onto the 3.4 branch for the next 8 years.
The 3.4 branch will be unmaintained upstream, that doesn't mean security fixes from newer branches cannot be backported. I'm already backporting fixes to the 3.2 branch for EL5. Admittedly, it seems hard to commit to this for the next 8 years thought, especially when done mostly on spare time. However, this is currently doable, so I'm not throwing the towel yet. One of the rules in EPEL (and Fedora, fwiw) is an update must be as seamless as possible, so this definitely exclude to move to another bugzilla branch within a release (at least not in the same package), the difference between Fedora and EPEL being obviously the lifespan of said release. I think the proper way to go for EPEL is to have parallel installable version of bugzilla, something along the line of bugzilla38, bugzilla40, bugzilla42, etc... This has already been done for several other packages. In bugzilla's case, I think this shouldn't be too hard to achieve and would allow for lots more flexibility. In case one of the version gets too tiresome to maintain, it can be properly announced and admins can move to the next release, on their own schedule. I guess this would be better discussed on the epel-devel mailing list than in a bug thought. If that suits you, feel free to start a thread there and then I'll close this bug.
Good points. I'd have no problem with a bugzilla42 package, personally, especially with Obsoletes that wouldn't be bad at all. I agree, it would be good to talk about on epel-devel, especially since Redhat's recent EOL extensions change the scope. Doubling the lifetime doesn't merely double the work - backports at year 10 are going to be much harder than at year 5. So I can start an informed discussion - how hard are Bugzilla version inter-updates these days? I used to run Bugzilla manually a decade ago, but now I'm well-spoiled by your packages!
(In reply to comment #2) > Good points. I'd have no problem with a bugzilla42 package, personally, > especially with Obsoletes that wouldn't be bad at all. > I think Obsoletes is not really an option here, but that's an implementation detail, let's save that for later. > I agree, it would be good to talk about on epel-devel, especially since > Redhat's recent EOL extensions change the scope. Doubling the lifetime doesn't > merely double the work - backports at year 10 are going to be much harder than > at year 5. > Agreed. > So I can start an informed discussion - how hard are Bugzilla version > inter-updates these days? I used to run Bugzilla manually a decade ago, but > now I'm well-spoiled by your packages! Basically, just run check-setup.pl and possibly make some adjustements here and there. Not a big deal really, but that cannot be triggered unattended from an rpm upgrade. People also may have special setup, 3rd party extensions, and tuning, and whatnot... But I'm not that experienced with bugzilla updates, you might know more than me. I've only taken over maintenance of this package less than one year ago. Actually, someone requested a bugzilla upgrade not too long ago, and I gave him basically the same answer, but I took a quick glance at the spec an I think creating parallel installable package really wouldn't need much in the spec file. Haven't tried to do it for real though, not am I sure I'll have the leisure to try any time soon. See https://bugzilla.redhat.com/show_bug.cgi?id=783000.
Just that obsoleteness of 3.4.* is now official http://lpsolit.wordpress.com/2012/02/23/bugzilla-4-2-released/
ping ... any activity here? I am willing to help with testing preliminary packages.
*** Bug 889550 has been marked as a duplicate of this bug. ***
(In reply to Bill McGonigle from comment #2) > Good points. I'd have no problem with a bugzilla42 package, personally, > especially with Obsoletes that wouldn't be bad at all. Actually, that would be bugzilla45 these days, wouldn't it?
(In reply to Matěj Cepl from comment #7) > (In reply to Bill McGonigle from comment #2) > > Good points. I'd have no problem with a bugzilla42 package, personally, > > especially with Obsoletes that wouldn't be bad at all. > > Actually, that would be bugzilla45 these days, wouldn't it? Sorry, bugzilla44
I have just tried to rebuild master for EL-6 and that succeeded (http://koji.fedoraproject.org/koji/taskinfo?taskID=6362741), unfortunately I didn't have all dependencies. Particularly Email::MIME and that failed to build on EL-6 with rather awful missing dependencies http://koji.fedoraproject.org/koji/taskinfo?taskID=6362763. Perhaps, if we don't have inbound email (who actually uses that?) we could do better?
Matěj, Email::MIME is a hard dependency for bugzilla, so I don't think trying to eliminate it is a good idea. Without going through dependency hell, we can fulfill the dependency by rebuilding perl-Email-MIME-1.906-1.fc15. One of the big issues is that __requires_exclude macros don't work on EL6 due to an old version of RPM resulting in hard dependencies for all those Perl modules that are actually optional. See https://fedorahosted.org/fpc/ticket/76. I think we can work around this in an acceptable manner since most of the dependencies are optional and the hard dependencies are statically listed in the spec file. I don't know what Fedora's packaging policy is on setting "AutoReq", but that's probably going to be the only way we'll get this packaged for EL6. So to get this working, here are the steps I took: - rebuild perl-Email-MIME-1.906-1.fc15 against EL6 - rebuild perl-Math-Random-ISAAC-1.004-9.fc20 against EL6 - build bugzilla-4.2.7-2.el6.src.rpm with the modified spec using AutoReq=0 This results in a functional bugzilla instance. I haven't run through any workflows, but I figure it checksetup.pl is happy, we're probably on the right track. I've attached working SRPMs for the whole stack. I'm not a Fedora packager so I can't put them through a scratch build in Fedora's Koji instance.
Created attachment 846794 [details] perl-Math-Random-ISAAC-1.004-9.el6
Created attachment 846795 [details] perl-Email-MIME-1.906-1.el6
Created attachment 846796 [details] bugzilla-4.2.7-2.el6
Koji builds: * perl-Email-MIME-1.906-1.el6 http://koji.fedoraproject.org/koji/taskinfo?taskID=6370910 When installing Transaction Check Error: file /usr/share/man/man3/Email::MIME::Modifier.3pm.gz from install of perl-Email-MIME-1.906-1.el6.noarch conflicts with file from package perl-Email-MIME-Modifier-1.444-1.el6.noarch file /usr/share/man/man3/Email::MIME::Creator.3pm.gz from install of perl-Email-MIME-1.906-1.el6.noarch conflicts with file from package perl-Email-MIME-Creator-1.456-1.el6.noarch * perl-Math-Random-ISAAC-1.004-9.el6 http://koji.fedoraproject.org/koji/taskinfo?taskID=6370912 * bugzilla-4.2.7-2.el6 http://koji.fedoraproject.org/koji/taskinfo?taskID=6370920
Installed on my https://luther.ceplovi.cz/bugzilla/ and it seems to work just fine.
When running checksetup.pl I get this: *********************************************************************** * OPTIONAL MODULES * *********************************************************************** * Certain Perl modules are not required by Bugzilla, but by * * installing the latest version you gain access to additional * * features. * * * * The optional modules you do not have installed are listed below, * * with the name of the feature they enable. Below that table are the * * commands to install each module. * *********************************************************************** * MODULE NAME * ENABLES FEATURE(S) * *********************************************************************** * PatchReader * Patch Viewer * * RadiusPerl * RADIUS Authentication * * SOAP-Lite * XML-RPC Interface * * JSON-RPC * JSON-RPC Interface * * JSON-XS * Make JSON-RPC Faster * * Test-Taint * JSON-RPC Interface, XML-RPC Interface * * HTML-Scrubber * More HTML in Product/Group Descriptions * * Encode-Detect * Automatic charset detection for text attachments * * Email-MIME-Attachment-Stripper * Inbound Email * * Email-Reply * Inbound Email * * TheSchwartz * Mail Queueing * * Daemon-Generic * Mail Queueing * * Apache-SizeLimit * mod_perl * *********************************************************************** Some of these don’t interest me (although they may interest others).
(In reply to Matěj Cepl from comment #14) > Koji builds: > > * perl-Email-MIME-1.906-1.el6 > http://koji.fedoraproject.org/koji/taskinfo?taskID=6370910 > > When installing > > Transaction Check Error: > file /usr/share/man/man3/Email::MIME::Modifier.3pm.gz from install of > perl-Email-MIME-1.906-1.el6.noarch conflicts with file from package > perl-Email-MIME-Modifier-1.444-1.el6.noarch > file /usr/share/man/man3/Email::MIME::Creator.3pm.gz from install of > perl-Email-MIME-1.906-1.el6.noarch conflicts with file from package > perl-Email-MIME-Creator-1.456-1.el6.noarch > > * perl-Math-Random-ISAAC-1.004-9.el6 > http://koji.fedoraproject.org/koji/taskinfo?taskID=6370912 > * bugzilla-4.2.7-2.el6 > http://koji.fedoraproject.org/koji/taskinfo?taskID=6370920 I don't get perl-Email-MIME-Creator or perl-Email-MIME-Modifier pulled in as dependencies. What else is on your system that pulled those in? (In reply to Matěj Cepl from comment #16) > When running checksetup.pl I get this: > > *********************************************************************** > * OPTIONAL MODULES * > *********************************************************************** > * Certain Perl modules are not required by Bugzilla, but by * > * installing the latest version you gain access to additional * > * features. * > * * > * The optional modules you do not have installed are listed below, * > * with the name of the feature they enable. Below that table are the * > * commands to install each module. * > *********************************************************************** > * MODULE NAME * ENABLES FEATURE(S) * > *********************************************************************** > * PatchReader * Patch Viewer * > * RadiusPerl * RADIUS Authentication * > * SOAP-Lite * XML-RPC Interface * > * JSON-RPC * JSON-RPC Interface * > * JSON-XS * Make JSON-RPC Faster * > * Test-Taint * JSON-RPC Interface, XML-RPC Interface * > * HTML-Scrubber * More HTML in Product/Group Descriptions * > * Encode-Detect * Automatic charset detection for text > attachments * > * Email-MIME-Attachment-Stripper * Inbound Email * > * Email-Reply * Inbound Email * > * TheSchwartz * Mail Queueing * > * Daemon-Generic * Mail Queueing * > * Apache-SizeLimit * mod_perl * > *********************************************************************** > > Some of these don’t interest me (although they may interest others). I personally don't have a need for any of those features.
(In reply to Aron Parsons from comment #17) > I don't get perl-Email-MIME-Creator or perl-Email-MIME-Modifier pulled in as > dependencies. What else is on your system that pulled those in? Something else brought them in. Just that in the case we do upgrade perl-Email-MIME* we need to be careful about obsoleting what’s obsolete + providing replacements.
Created attachment 847208 [details] perl-Email-MIME-1.906-1.el6 updated updated perl-Email-MIME with Provides and Obsoletes set for perl-Email-MIME-Creator and perl-Email-MIME-Modifier
http://koji.fedoraproject.org/koji/taskinfo?taskID=6374550
Matěj, I am running this on our production bugzilla instance. It's not large or complex by any means, but the upgrade process using checksetup.pl went smooth and all functionality is intact (email, LDAP, submitting bugs, comments, attachments). Do you see anything that would prevent us from pushing forward with these updates for EPEL6?
I don't. Works for my personal bugzilla (https://luther.ceplovi.cz/bugzilla) like a clock. Unfortunately, I am not a package maintainer of the bugzilla package, so it is not up to me to make the call.
Itamar, As the maintainer of bugzilla in EPEL6, what are your thoughts on the way forward?
*** Bug 957813 has been marked as a duplicate of this bug. ***
Created attachment 887605 [details] proposed spec Could somebody help me to filter correctly provides? I have tried this (thanks to Marcela Mašláňová for help; the equivalent for requires, but there is more of them): [matej@santiago bugzilla]$ grep __provides_ bugzilla.spec ## %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(CGI\\)\\s*$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::BmpConvert\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::Example\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::Example::Auth::Login\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::Example::Auth::Verify\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::Example::Config\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::Example::WebService\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::OldBugMove\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::OldBugMove::Params\\)$ %global __provides_exclude %{?__provides_exclude:%__provides_exclude|}^%{?scl_prefix}perl\\(Bugzilla::Extension::Voting\\)$ [matej@santiago bugzilla]$ But it doesn’t seem to work [matej@santiago bugzilla]$ rpm -qp --provides noarch/bugzilla-4.2.8-2.0.2.MCbugzilla42.el6.noarch.rpm |grep Bugzilla::Extension perl(Bugzilla::Extension) perl(Bugzilla::Extension::BmpConvert) perl(Bugzilla::Extension::BmpConvert) = 1.0 perl(Bugzilla::Extension::Example) perl(Bugzilla::Extension::Example) = 1.0 perl(Bugzilla::Extension::Example::Auth::Login) perl(Bugzilla::Extension::Example::Auth::Verify) perl(Bugzilla::Extension::Example::Config) perl(Bugzilla::Extension::Example::Util) perl(Bugzilla::Extension::Example::WebService) perl(Bugzilla::Extension::OldBugMove) perl(Bugzilla::Extension::OldBugMove::Params) perl(Bugzilla::Extension::Voting) [matej@santiago bugzilla]$ What I do wrong?
Notice that this bug (and my effort) is for EPEL-6 so all macros must stay compatible with RHEL-6.
I feel really ashamed to have let bugzilla rot the way it is now, but I have finally been able to commit some time to it. Going to bugzilla 4.4 is not possible for EL6 because of dependencies on base packages that cannot be upgraded (perl-TimeDate 2.23 needed, 2.22 available ; perl-List-MoreUtils 0.32 needed, 0.22 available). Going to bugzilla 4.2 is possible though, but it would need proper announcement on the epel mailing list, as it will not be an unattended upgrade. I have not tested an upgrade from a 3.4 bugzilla instance, but I'll try to set up a test box in the coming weeks. I have not much hope for bugzilla 3.2 that is currently in EPEL5, but I haven't tried either. I just don't feel like adding yet another mean to filter requires/provides and fight the old perl packages in base EL5. I guess the best to do at this point is probably to just retire it. So for bugzilla 4.2 in EL6 : - perl-Email-MIME needs to be upgraded to git tag perl-Email-MIME-1.906-2.fc15. Later versions have unmet dependencies. - perl-Math-Random-ISAAC needs to be branched and built. - EL6 compatible Provides/Requires filtering needs to be added to bugzilla 4.2 as currently found in the f20 branch (See attached patch against f20 branch). Once that done, checksetup.pl goes fine and I was able to quickly setup an empty instance. What I can commit to is to update perl-Email-MIME, ask for branch and build perl-Math-Random-ISAAC, talk to Fedora bugzilla maintainer to get the EL6 filtering added to the fedora branches in order to keep branch as much as possible in sync and allow to just merge the f20 branch when needed. However, what I cannot commit to, as the state of bugzilla as proved now, is to keep maintaining it properly, especially as my focus at work as shifted to other tasks a long time ago, and thus I'd like to get some active co-maintainers to join. Who's in ? Please note none of this is going to address the fact that bugzilla 4.2 branch will not be supported for the whole EPEL6 life. At this point, I have given up any hope to be able to backport fixes once the branch will go unmaintained upstream. That doesn't mean it's not possible, that just means it's way more time than I'm able to devote to the task. And anyway, the EPEL guidelines are probably going to evolve at some point, and such non unattended updates are probably going to be allowed in some way.
Created attachment 936670 [details] patch against f20 branch with deps filtering for EL6.
bugzilla has been marked as dead.package for el6, closing this as won't fix, it's not possible to upgrade bugzilla to a newer version without upgrading el6 base packages.