This bug is meant to be a tracker bug to track rt > 3.9's (supposed to become rt-4.0.0) package dependencies.
rt4 was released Apr 28, 2011. Provided how this bug was processed, Fedora 15 will not have rt4.
Are there any updates on getting RT 4 packaged?
De-facto no. I am still working on this as a "low-priority side-job", but there have been technical issues (e.g. the changes in rpm's perl-deptracking), which so far have prevented progress.
*** Bug 781813 has been marked as a duplicate of this bug. ***
Note that Best practical has moved to git https://github.com/bestpractical/ ( which you are probably already aware of ) What's your thought/take about packaging all the available extension and potentially any other useful external bits that can be found there and are supported by rt4 ( https://github.com/bestpractical/repositories?page=5 )?
(In reply to comment #5) > Note that Best practical has moved to git https://github.com/bestpractical/ > ( which you are probably already aware of ) Well, so far this isn't much more but a change in their internal work flow, which is not of much importance to fedora. I am using their released tarballs: http://www.bestpractical.com/rt/download_file.html > What's your thought/take about packaging all the available extension and > potentially any other useful external bits that can be found there and are > supported by rt4 ( https://github.com/bestpractical/repositories?page=5 )? I haven't checked yet. Theoretically these should be packaged as perl-modules (perl-rt-<whatever) and integrate into Fedora's vendor-perl. However, rt has always had a lot of problems related to integrate into a vendor-perl, so I am expecting the worst.
(In reply to comment #3) > I am still working on this as a "low-priority side-job", but there have been > technical issues (e.g. the changes in rpm's perl-deptracking), which so far > have prevented progress. I work for upstream (Best Practical) -- if you're running into problems packaging RT4 that we can help with, please drop rt-devel[1] mail, or pop onto IRC[2]. We know there are a number of folks that depend on RPM packaging, so we'd love to support your effort. [1] http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel [2] #rt on irc.perl.org
Sneak preview at rt4 package prototypes: http://corsepiu.fedorapeople.org/packages/ Any feedback welcome. Notes: * These packages replace the rt3 packages and do not allow parallel installation of rt3 and rt4. I am considering to finally abandon my initial intention to allow parallel installation of rt3 and rt3 and to rename the rtX packages into "plain rt". * rpmlint is very verbose on these packages, but 99% of this is ignorable non-sense. These rt3 packages are derived from my rt3 packages and very similar to it. * I tested this with f16 only. Finally, apologies for it having taken so long with a workable set of rpms, but the delay is the result of a long chain of in Fedora, rt's development and on my part.
(In reply to comment #5) > What's your thought/take about packaging all the available extension and > potentially any other useful external bits that can be found there and are > supported by rt4 ( https://github.com/bestpractical/repositories?page=5 )? Which extensions in particular are you interested in?
Sorry for my late response somehow this got lost in my bugzilla folder in my inbox. The first thing that pops up to my mind is shipping all the authentication extension ( ldap etc ). I think at least those should be shipped as default. With regards to the naming of the package I would think that they should be named rt3-x and rt4-x since the 3.x release of rt seems to be still supported or we should be using whatever naming scheme other distribution are using. I guess to be able to get the rt 4.x release into the distribution at this point for F17 it has to be introduced under as an new package under a new name.
seconded for RT::Authen::ExternalAuth. Also, I'd be interested in something that would allow me to make fields mandatory. Right now, BestPractical seems to support MandatoryRequestor (http://search.cpan.org/dist/RT-Extension-MandatoryRequestor/) and MandatorySubject (http://search.cpan.org/dist/RT-Extension-MandatorySubject/), but more interesting would be the more general-purpose MandatoryFields (http://search.cpan.org/dist/RT-Extension-MandatoryFields/). In fact, I'm considering packaging the latter for Fedora, unless it's likely to be included as an rt4 subpackage...
Ralf I was looking into having us in QA switch to use RT4 instead of trac where are we with this exactly? Bug 664920 has Jon Ciesla 2012-08-14 09:23:14 EDT Git done (by process-git-requests). So is there anything preventing you from going ahead with an rt4 package?
(In reply to comment #12) > Ralf I was looking into having us in QA switch to use RT4 instead of trac > where are we with this exactly? > > Bug 664920 has > > Jon Ciesla 2012-08-14 09:23:14 EDT > Git done (by process-git-requests). I just closed it ... > So is there anything preventing you from going ahead with an rt4 package? I'll have to check. I have a local rt4 package, I last touched back in February and would have to update it.
(In reply to comment #13) > I have a local rt4 package, I last touched back in > February and would have to update it. This just happened. Sneak preview: http://corsepiu.fedorapeople.org/packages/ I intend to file a formal review, soon after some more testing. If not today, then likely to happen after Christmas.
Add Tracking keyword to avoid bug closure during Rawhide rebase process.
I have Ralf's 4.0.8 package built and running on EL7 - initial testing looks good. There are a slew of perl module packages in f20 that are not (yet?) in EPEL 7 - I've built the f20 packages on el7 without incident and put up sources and binaries here: https://www.bfccomputing.com/downloads/fedora/rt/el7/rt4/ in case anybody else here wants to help test. I'm going to shake this out for a little bit before looking at 4.2 (assuming we ought to ship the current revision). If you want to build the sources, the only tricky part is you need to --define perlbootstrap=1 for perl-HTML-TreeBuilder-LibXML because there is a circular dependency with perl-Web-Scraper (per bug 982293). You shouldn't need to build unless you want to verify the binaries. It would be great to see these all pushed into EPEL7 - if somebody knows the polite way to request 65 package builds, please comment.
(In reply to Bill McGonigle from comment #16) > I have Ralf's 4.0.8 package built and running on EL7 - initial testing looks > good. Sigh, provided the tedious and tiresome reviews it had required to get the packages required for rt4 into Fedora, rt4 has dropped a little off from my personal radar this year. Provided the fact rt3 has been discontinued upstream, I'd really like to see rt4 > 4.0 at least in Fedora > 20 and to discontinue rt3 there. Anyway, I have been experimenting with 4.0.x and 4.2.x packages for Fedora. So far, my experiences with 4.0.x were quite positive, while my experiences with 4.2.x are quite dissatisfactory. ATM. I have 4.0.20 packages (4.0.21 was released yesterday) and at 4.2.3 packages for Fedora. I guess, you just pushed me to submit my 4.0.x packages for review after having upgraded them to 4.0.21 and having run of local tests later today/early next week. > I'm going to shake this out > for a little bit before looking at 4.2 (assuming we ought to ship the > current revision). C.f. above. I can upload my 4.2 version to fedorapeople.org for testing, but ... unlike my 4.0.x packages, these definitely need major work.
I just uploaded rt-4.0.21 for review: https://bugzilla.redhat.com/show_bug.cgi?id=1121601