The 1.3.0-1 bcfg2 package throws an exception, pasted below. I have not dug into the problem, but a quick search turned up this thread on the bcfg2-devel list, where Sol points to a bug in the Fedora specfile:
I propose the Fedora specfile be based on the upstream sources. Several of my contributions have been accepted into the upstream specfile, and it works fine on at least el6. If the Fedora bcfg2 package maintainers are willing to go this route, I'll be happy to take responsibility for ensuring the upstream specfile works for all Fedora releases. In addition, I'll be happy to co-maintain the bcfg2 package.
Traceback (most recent call last):
File "/usr/sbin/bcfg2-info", line 16, in <module>
File "/usr/lib/python2.6/site-packages/Bcfg2/Server/Core.py", line 14, in <module>
In the last couple of months I only follow upstream sporadically. Every help would be appreciated. Please go ahead and make the changes.
Thanks, Fabian! I'll work on this over the weekend. Hope you'll give the changes your blessing before I commit. :)
This bug is fixed, and a bunch of other changes made, pushed to the 'master' branch. The packages are confirmed to build on el5/6 and f17-19. I have done minor testing on my el6 install.
Fabian, if you can find a little time, I'd appreciate it if you'd bless them (criticism is welcome, too!).
Major changes are the update to 1.3.2 and the %check script.
A minor-looking change that calls for testing is the switch to python-inotify. Chris St. Pierre told me on the list some time back that this is much better than gamin.
Other minor fixes, including the fix to the bug in this ticket. :)
- Update to new upstream version 1.3.2
- Move settings.py into server package (fixes bug reported on bcfg2-dev ML)
- Use init scripts from redhat/scripts directory
- Fix EL5/EL6 sphinx docs
- Require python-inotify instead of gamin-python; recommended by upstream
- Remove obsolete bcfg2-py27-auth.patch, accepted upstream
- Add %%check script
- Hack test suite to use local copies of XMLSchema.xsd and xml.xsd
- Many new BRs to support %%check script
- Disable %%check script on EL5, where there is no python-mock package
- Cleanups to _pre/_rc macros
- Mark EL5 relics
- Other minor formatting
If no objections, I'll commit these changes to the other branches and run the packages through bodhi.
By the way, very nice package. It has quite a few things that the upstream specfile needs.
As I just posted to the bcfg2-dev list, I haven't dropped this. :)
I talked with upstream, and ended up agreeing to merge the Fedora and upstream specfiles as best as possible. I have a rough version ready, but it still needs testing, and also a few questions need answering. Probably something worth committing in a week or so.
Thanks for waiting!
Finally got the merge work done. Please see the email to bcfg-dev:
Fabian, a couple of questions about your preferences. First, hope you're ok with this reconciliation of the Fedora and upstream (misc/bcfg2.spec) specfiles.
How do you feel about making the Fedora specfile identical to the upstream version? The upstream version contains macros and code to support OpenSUSE and Mandriva. Chris St. Pierre inquired on #fedora-devel, where someone said this might be ok as long as the result is readable. I'm fine with it, since it might make maintenance easier in the future. Here's a pastebin of the diff:
The other question is, what do you think about merging the bcfg2-examples package into bcfg2-doc? I'm indifferent; Chris St. Pierre said he prefers a single package.
The email thread can be read here:
Here are the changes I'm working on to both Fedora and upstream packages:
(In reply to John Morris from comment #6)
> Fabian, a couple of questions about your preferences. First, hope you're ok
> with this reconciliation of the Fedora and upstream (misc/bcfg2.spec)
I'm ok with that.
> How do you feel about making the Fedora specfile identical to the upstream
> version? The upstream version contains macros and code to support OpenSUSE
> and Mandriva. Chris St. Pierre inquired on #fedora-devel, where someone
> said this might be ok as long as the result is readable. I'm fine with it,
> since it might make maintenance easier in the future. Here's a pastebin of
> the diff:
If it keeps the maintenance process simpler why not.
> The other question is, what do you think about merging the bcfg2-examples
> package into bcfg2-doc? I'm indifferent; Chris St. Pierre said he prefers a
> single package.
I can't remember why the doc and the examples were split in the first place. Well, merging them doesn't harm.
The reconciliation with the upstream specfile is complete. Closing bug.
Whoops, closing bug for real this time!