Bug 624594
| Summary: | Update kobo to 0.3.0: "AttributeError: 'CommandContainer' object has no attribute 'set_hub'" | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Michal Nowak <mnowak> | ||||||||
| Component: | command line | Assignee: | Bill Peck <bpeck> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 0.5 | CC: | azelinka, bpeck, dcallagh, dkutalek, dmach, kbaker, mcsontos, ohudlick, psplicha, rmancy, sassmann | ||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2010-09-07 15:13:45 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
It's due to kobo update from EPEL kobo.noarch 0:0.3.0-2.el6 kobo-client.noarch 0:0.3.0-2.el6 Old kobo* kobo-client-0.2.1-1.el6.noarch kobo-0.2.1-1.el6.noarch is fine. Update beaker to kobo 0.3.0, please. *** Bug 625346 has been marked as a duplicate of this bug. *** From what I can tell, kobo 0.3 is not even in a stable epel repo, it's still in testing. We should have a look at what the problem may be, but for the meantime downgrade to a stable epel kobo. cc'ing Daniel Mach. Daniel, any pointers on the kobo lib? (In reply to comment #5) > cc'ing Daniel Mach. Daniel, any pointers on the kobo lib? Sure, it's caused by new configuration handling in client. It's documented in kobo-0.3 release notes. Already wrote a patch and emailed it to bpeck. Attaching it here as well. Created attachment 440295 [details]
patch client to work with kobo-0.3
Created attachment 440339 [details] kobo-0.2 backwards-compatible patch The attached patch works for me on F13 with both kobo-0.2 and kobo-0.3. Ray, it's the bz624594 branch. Are you serious with the type-less except? That would catch all exceptions even if kobo-0.3 is installed. Let me give you an example: invalid config file syntax, exception raised on line 22. BTW, I still don't understand why you need kobo-0.2 compatibility. Why can't you just apply my patch and update Requires: in spec? Now I'm holding kobo-0.3 update in Fedora testing, you should have plenty time to make a new build and push beaker & kobo updates to stable at the same time. > That would catch all exceptions even if kobo-0.3 is installed. > Let me give you an example: invalid config file syntax, exception raised on > line 22. No, it would not: it would catch exceptions in imports (and in the _class definition_ too, but there are no exceptions there). But you are right, it is bad practice and it is fixed. Thanks for the review. > BTW, I still don't understand why you need kobo-0.2 compatibility. > Why can't you just apply my patch and update Requires: in spec? I just want the update to work regardless of dependencies. Feel free to call me paranoic, but if you met a group of antiparticles tonight, I would like to keep it working. (In reply to comment #10) > > BTW, I still don't understand why you need kobo-0.2 compatibility. > > Why can't you just apply my patch and update Requires: in spec? > > I just want the update to work regardless of dependencies. Feel free to call me > paranoic, but if you met a group of antiparticles tonight, I would like to keep > it working. If you think so... From my point of view it's just another useless code you have to maintain. (In reply to comment #11) > (In reply to comment #10) > > > BTW, I still don't understand why you need kobo-0.2 compatibility. > > > Why can't you just apply my patch and update Requires: in spec? > > > > I just want the update to work regardless of dependencies. Feel free to call me > > paranoic, but if you met a group of antiparticles tonight, I would like to keep > > it working. > > If you think so... > From my point of view it's just another useless code you have to maintain. Marian, Daniel may have a point. Is there any reason to carry kobo-0.2 compat? What is the impact if we don't? Excuse me. It's the first time I met with broken dependencies on this ship and forgot package manager would help us to keep it working. Thanks for patience. Anyway it may be too late changing things which work fine. May be adding deprecation warning would help and I would push Dan's patch week after next when kobo-0.3 is safely out. Created attachment 440750 [details]
deprecation warning
Is it any better now?
And this reminds me we should be more strict about requirements and supported versions in our spec files.
[Disclaimer: I am not a spec-file proficient and I am not brave enough tinkering with it now.]
I'll make a branch for Daniel's diff. Marian, no it seems we don't have version requirements in our spec (except I think cobbler); We probably should be. (In reply to comment #13) > Excuse me. It's the first time I met with broken dependencies on this ship and > forgot package manager would help us to keep it working. Thanks for patience. no problem :) > Anyway it may be too late changing things which work fine. May be adding > deprecation warning would help and I would push Dan's patch week after next > when kobo-0.3 is safely out. If I push kobo right now to Fedora stable, it will break beaker in Fedora until you push the fix. I'm holding the kobo update to push both kobo and patched beaker simultaneously. This also means it should be safe to use my original patch and skip any deprecation warnings. I've used patch in comment 7 http://git.fedorahosted.org/git/?p=beaker.git;a=commit;h=17d262cd533a9b25117c69373ab3b4521e23f6c3 Will be released tomorrow Sorry, but bkr client is still not working for me with kobo 0.3.0-2.el6. Reopenning the bug. beaker-client-0.5.56 has been pushed to the repo. |
architecture: x86_64 component: beaker executable: /usr/bin/bkr kernel: 2.6.32-63.el6.x86_64 package: beaker-client-0.5.52-3.el6 reason: plugins.py:51:__getattr__:AttributeError: 'CommandContainer' object has no attribute 'set_hub' release: Red Hat Enterprise Linux release 6.0 Beta (Santiago) sosreport.tar.xz: /var/spool/abrt/pyhook-1282028717-22673/sosreport.tar.xz time: 1282028717 uid: 500 backtrace ----- plugins.py:51:__getattr__:AttributeError: 'CommandContainer' object has no attribute 'set_hub' Traceback (most recent call last): File "/usr/bin/bkr", line 9, in <module> load_entry_point('bkr.client==0.5.52', 'console_scripts', 'bkr')() File "/usr/lib/python2.6/site-packages/bkr/client/main.py", line 32, in main return parser.run() File "/usr/lib/python2.6/site-packages/kobo/cli.py", line 270, in run cmd.run(*cmd_args, **cmd_kwargs) File "/usr/lib/python2.6/site-packages/bkr/client/commands/cmd_workflow_simple.py", line 24, in run requestedTasks = self.getTasks(*args, **kwargs) File "/usr/lib/python2.6/site-packages/bkr/client/__init__.py", line 226, in getTasks self.set_hub(username, password) File "/usr/lib/python2.6/site-packages/kobo/plugins.py", line 51, in __getattr__ return getattr(self.container, name) AttributeError: 'CommandContainer' object has no attribute 'set_hub' Local variables in innermost frame: self: <kobo.plugins.Workflow_Simple object at 0xb2d050> name: 'set_hub' reproduce ----- 1. bkr workflow-simple --distro RHEL6.0-20100805.0 --variant Server --task /CoreOS/xerces-c/Sanity/bz593687-testsuite --whiteboard /CoreOS/xerces-c/Sanity/bz593687-testsuite --arch ppc64 --arch i386 --arch s390x