In connection with bug 750474 (and indirectly bug 741324), I have found out that (despite strongly discouraging luci + EPEL packages combination) the actual cause of luci not starting up is the fact "requires" item of metadata is not consistent between RPM and contained Python package. Practically: # /usr/bin/paster make-config luci /var/lib/luci/etc/luci.ini \ --no-default-sysconfig --no-install [...] Traceback (most recent call last): [...] pkg_resources.VersionConflict: (WebOb 0.9.6.1 (/usr/lib/python2.6/site-packages), Requirement.parse('WebOb>=0.9.7')) # grep -rnE "WebOb[ ]*>=[ ]*0.9.7" /usr/lib*/python*/site-packages /usr/lib/python2.6/site-packages/ repoze.who_friendlyform-1.0.8-py2.6.egg-info/requires.txt:3:WebOb>=0.9.7 # cat [...]repoze.who_friendlyform-1.0.8-py2.6.egg-info/requires.txt repoze.who >= 1.0 zope.interface WebOb>=0.9.7 # rpm -qR python-repoze-who-friendlyform python(abi) = 2.6 python-repoze-who >= 1.0 python-zope-interface rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 # rpm -q python-repoze-who-friendlyform python-repoze-who-friendlyform-1.0.8-2.el6.noarch As can be seen, python-webob >= 0.9.7 requirement is missing in RPM/spec. And as Tom mentioned in bug 741324 comment 5, the original dependency won't be accidental. The explanation for this can be that python-webob is missing in EPEL, but such workaround is IMHO short-sighted.
The most obvious fix would be for the python-webob package in RHEL to increment to 0.9.7. I cannot put python-webob into EPEL, because it is in base RHEL. The only other solution is to remove python-repoze-who-friendlyform from EPEL, but that would also require removing python-fedora-turbogears2 from EPEL, which I believe is necessary for Fedora Infrastructure deployment on RHEL.
Oh, I hadn't checked whether python-webob is in base RHEL and the reason is a bit of mystery for me looking at the output of --- repoquery -a --tree-whatrequires python-webob --- on RHEL 6.1 (with EPEL disabled). What I meant was to gently point out that respective python-webob is missing in EPEL (enabled by weaker RPM dependencies then declared by upstream in the Python package) and it can cause not so obvious issues as demonstrated on the case of luci (maybe it is not a good idea to mute the initialization commands within its initscript completely, but the message is not much clear, anyway). I understand the politics of not causing collisions EPEL vs. base RHEL, though. > The only other solution is to remove python-repoze-who-friendlyform from > EPEL, but that would also require removing python-fedora-turbogears2 from > EPEL, which I believe is necessary for Fedora Infrastructure deployment > on RHEL. I believe the very same problem as with luci apply to Fedora Infrastructure. Provided that they need python-repoze-who-friendlyform from EPEL, they have to get the correct version of python-webob (WebOb Python package) somewhere, and that somewhere is surely not EPEL (missing this package) nor RHEL repository as the local version is 0.9.6.1 <= 0.9.7. So they either have a specific workaround or do not use the EPEL version of python-repoze-who-friendlyform at all. I hope I am not missing anything in such counterexample of python-repoze-who-friendlyform necessity in EPEL. If nothing else, your first proposed solution might have a positive impact, but apparently it would be in RHEL 6.3+ at earliest. Presumably WebOb >= 0.9.7.1 would be then desirable [1]. [1] http://docs.webob.org/en/latest/news.html
I'm not sure why their python-repoze-who-friendlyform isn't broken, you're right, it should exhibit the same problem. It's possible they're not actually using it, its just being pulled in as a dep. I suppose I could downgrade python-repoze-who-friendlyform in EPEL and bump the Epoch, but then it would unnecessarily trump all future RHEL Cluster packages. :P FWIW, I don't think RHEL has any plans to update WebOb, unless you're being coy and are actually the python-webob RHEL maintainer... :) Assuming that you're not, can you put in a bug to have webob bumped to at least 0.9.7 to resolve this issue? Once that's done, I can simply add the Requires: to the python-repoze-who-friendlyform EPEL package and all should be well.
> I believe the very same problem as with luci apply to Fedora > Infrastructure. I should have posted the whole traceback: > Distribution already installed: > luci 0.23.0 from /usr/lib64/python2.6/site-packages > Traceback (most recent call last): > File "/usr/bin/paster", line 9, in <module> > load_entry_point('PasteScript==1.7.3', 'console_scripts', 'paster')() > File "/usr/lib/python2.6/site-packages/paste/script/command.py", > line 84, in run > invoke(command, command_name, options, args[1:]) > File "/usr/lib/python2.6/site-packages/paste/script/command.py", > line 123, in invoke > exit_code = runner.run(args) > File "/usr/lib/python2.6/site-packages/paste/script/appinstall.py", > line 68, in run > return super(AbstractInstallCommand, self).run(new_args) > File "/usr/lib/python2.6/site-packages/paste/script/command.py", > line 218, in run > result = self.command() > File "/usr/lib/python2.6/site-packages/paste/script/appinstall.py", > line 295, in command > self.distro, self.options.ep_group, self.options.ep_name) > File "/usr/lib/python2.6/site-packages/paste/script/appinstall.py", > line 234, in get_installer > 'paste.app_install', ep_name) > File "/usr/lib/python2.6/site-packages/pkg_resources.py", > line 2229, in load_entry_point > return ep.load() > File "/usr/lib/python2.6/site-packages/pkg_resources.py", > line 1947, in load > if require: self.require(env, installer) > File "/usr/lib/python2.6/site-packages/pkg_resources.py", > line 1960, in require > working_set.resolve(self.dist.requires(self.extras),env,installer)) > File "/usr/lib/python2.6/site-packages/pkg_resources.py", > line 550, in resolve > raise VersionConflict(dist,req) # XXX put more info here > pkg_resources.VersionConflict: > (WebOb 0.9.6.1 (/usr/lib/python2.6/site-packages), > Requirement.parse('WebOb>=0.9.7')) Maybe if Fedora Infrastructure is run such that PasteScript is not involved, this proactive check of fulfilling requirements is not in place. Still it holds that the dependency requirement is there for a reason and it is probably not easy to say "in our case, it doesn't matter at all" (in case they keep using python-repoze-who-friendlyform 0.9.6.1). > [...] can you put in a bug to have webob bumped to at least 0.9.7 to > resolve this issue? Once that's done, I can simply add the Requires: to > the python-repoze-who-friendlyform EPEL package and all should be well. Sure, bug 751202.
Fedora Infra seems to be running TurboGears2 from the infrastructure repository for RHEL6. We're likely updating something (possibly we have a custom webob package..) to make things work. lmacken says that we only have one app that still uses TG2 and we should be able to kill the python-fedora-tg2 code without impacting that. So we're probably going to go that route, getting rid of our tg2 (and python-webob and friendlyform dependencies). From an EPEL standpoint, we found, today, that the python-repoze-who-friendlyform package is being provided by Server-ha. Since we build with the server-ha channel, that means we need to remove the python-repoze-who-friendlyform so as not to conflict. If we need newer versions of these in EPEL, it is possible to create forward compat packages for them in EPEL. It would use: https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions and possibly some patching of application code in order to use the necessary versions of the packages.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version, you are encouraged to change the 'version' to a later version prior this bug is closed as described in the policy above.
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of EPEL please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.