[three]Bean
fedmsg - to staging and beyond
Jul 11, 2012 | categories: fedmsg, fedora View CommentsI've been working for a little while on fedmsg, a set of tools for developing a Fedora Infrastructure message bus... and I need to share it with you.
If you want to get involved, hit me up in IRC on freenode in
#fedora-apps
-- I'm threebean
there.
Ship It!
Jun 15, 2012 | categories: python, fedora View CommentsI just got into this whole Fedora packaging thing and found myself annoyed by all the waiting-on-koji-to-build. It's always the same kind of thing:
$ git commit -a -m 'Initial commit (#12345)' $ fedpkg push $ fedpkg build <wait wait wait> $ fedpkg switch-branch f17 $ git merge master $ fedpkg push $ fedpkg build <wait wait wait> $ fedpkg update <type type type> $ bodhi --buildroot-override BLAH $ fedpkg switch-branch el6 $ git merge master $ fedpkg push $ fedpkg build <wait wait wait> $ fedpkg update <type type type> $ bodhi --buildroot-override BLAH $ echo "le sigh"
I had to do this for the whole python-tw2 stack!
In answer, I wrote a baby scriptlet called ship-it to smooth it over. It uses the unbelievably re__dict__ulous pbs python module to do the dirty work (coming soon to a Beefy Miracle near you as python-pbs-subprocess):
#!/usr/bin/env python """ Script for merging, pushing, building, updating, and buildroot-overriding changes to a package on multiple branches. Run this after you have made a change, committed and built the master branch for your new package. """ import argparse import textwrap # The pbs module is amazing. from pbs import git, fedpkg, bodhi, rpmspec, glob branches = [ { 'short': 'f17', 'long': 'fc17', }, { 'short': 'el6', 'long': 'el6', }, ] def config(): parser = argparse.ArgumentParser( description=textwrap.dedent(__doc__), formatter_class=argparse.RawDescriptionHelpFormatter, ) parser.add_argument( '--user', dest='user', help='Your FAS username.') parser.add_argument( '--type', dest='type', help="Type. (bugfix, enhancement, security)") parser.add_argument( '--bugs', dest='bugs', help="Specify any number of Bugzilla IDs (--bugs=1234,5678)") parser.add_argument( '--notes', dest='notes', help='Update notes') parser.add_argument( '--duration', dest='duration', type=int, default=7, help="Duration of the buildroot override in days.") parser.add_argument( '--forgive-build', dest='forgive', action='store_true', default=False, help="Don't stop the script if a build fails.") args = parser.parse_args() required_args = ['user', 'type', 'notes'] for required in required_args: if not getattr(args, required): parser.print_usage() raise ValueError("%r is required." % required) return args def main(): args = config() spec = glob("*.spec")[0] nevr = rpmspec(q=spec).split()[0].rsplit('.', 2)[0] print "Processing %r" % nevr for branch in branches: nevra = nevr + '.' + branch['long'] print "Working on %r, %r" % (branch['short'], nevra) print git.checkout(branch['short']) # Merge, push, build git.merge("master", _fg=True) fedpkg.push(_fg=True) if args.forgive: try: fedpkg.build(_fg=True) except Exception, e: print str(e) else: fedpkg.build(_fg=True) # Submit a new update. kwargs = { '_fg': True, 'new': True, 'user': args.user, 'type': args.type, 'notes': args.notes, } bodhi(nevra, **kwargs) # Buildroot override kwargs = { '_fg': True, 'user': args.user, 'buildroot-override': nevra, 'duration': args.duration, 'notes': args.notes, } bodhi(**kwargs) if __name__ == '__main__': main()
Re-scheduling the Fedora Messaging SIG meetings
May 11, 2012 | categories: fedora View CommentsThe Messaging SIG has been meeting on Tuesdays at 16.00 UTC. Turnout has been a little low and we concluded that it's not the best time.
If you're interested in participating in meetings, please fill out the following survey so I can get a good idea of when to place them:
http://whenisgood.net/fedmsg
For the curious, here's a list of the archived meeting logs:
https://github.com/ralphbean/fedmsg/blob/develop/doc/meetings.rst
Are my Fedora packages handled by Upstream Release Monitoring?
May 02, 2012 | categories: python, fedora View CommentsI just recently started packaging up a bunch of stuff for Fedora 17 and have had to learn the ins-and-outs of package review. The final step in the how-to-get-your-package-into-Fedora story is to enable upstream release monitoring for your package.
I'd forgotten to do this a few times. Oop! So I wrote the following little script to ask pkgdb for all my packages, compare them against the list of monitored packages, and print the result. Maybe you'll find it useful:
#!/usr/bin/env python """ List the Fedora packages I own by their status in Upstream Release Monitoring. Requires python-fedora:: $ sudo yum install python-fedora """ import fedora.client import requests from kitchen.text.converters import to_unicode import os URL = "http://fedoraproject.org/wiki/Upstream_release_monitoring" symbols = { False: ' - ', True: ' + ', } if __name__ == '__main__': pkgdb = fedora.client.PackageDB() username = os.environ.get("BODHI_USER") print "* Packages for FAS user %r" % username pkgs = pkgdb.user_packages(username).pkgs # Bypass varnish cache -> http://bit.ly/XF4YBy headers = {'Cookie': 'this-is-not-a-cookie'} page = requests.get(URL, headers=headers).text for pkg in pkgs: print symbols[pkg.name in page], pkg.name
Scheduling meetings for the Fedora Messaging SIG
Mar 05, 2012 | categories: zeromq, fedmsg, fedora, moksha View CommentsSo I'm spinning up the Fedora Messaging SIG. It's been sitting idle for years; this time we're really going to do it. We're going to put 0mq messaging hooks into bodhi, koji, pkgdb, fas, you name it.
I'm building a python module called fedmsg to wrap it all and it comes with a proposal-in-development. And if you're not excited yet, we've already 0mq enabled the Moksha Hub and achieved a ~100 times speedup over AMQP/qpid.
The point of this post is to ask about times for an IRC meeting of the Messaging SIG. Right now I'm thinking Tuesdays at 16:00-17:00 UTC in #fedora-meeting. If you're interested in helping with the effort but that's a bad time for you, let me know and we'll work it out.
I'll be out at PyCon until next Wednesday; so the first meeting won't be until March 20th at the earliest.
« Previous Page