Bug#645897: ITP: nosexcover -- Add Cobertura-style XML coverage report to nose
2012/6/19 Guido Günther a...@sigxcpu.org: On Wed, Oct 19, 2011 at 03:17:33PM +0200, Soren Hansen wrote: Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name : nosexcover Any news on this one? Sorry, no. I lost my momentum. If you want to take it over, feel free. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPFUtkbKKGhjk78A3x_Ha=ipola8le5hg851p1h-fu10sec...@mail.gmail.com
Bug#645882: ITP: python-riak -- Python client for Riak
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: python-riak Version : 1.3.0 Upstream Author : Basho Technologies r...@basho.com * URL : https://github.com/basho/riak-python-client * License : Apache 2.0 Programming Lang: Python Description : Python client for Riak Riak is a Dynamo-inspired database that is being used in production by companies like Mozilla and Comcast. Riak scales predictably and easily and simplifies development by giving users the ability to quickly prototype, test, and deploy their applications. A truly fault-tolerant system, Riak has no single point of failure. No machine is special or central in Riak, so developers and operations professionals can decide exactly how fault-tolerant they want and need their applications to be. This package provides a Python library to talk to Riak -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019104303.4423.30849.reportbug@localhost6.localdomain6
Bug#645902: ITP: kombu-sqlalchemy -- Kombu transport using SQLAlchemy as the message store
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: kombu-sqlalchemy Version : 1.1.0 Upstream Author : Ask Solem a...@celeryproject.org * URL : http://github.com/ask/kombu-sqlalchemy/ * License : BSD Programming Lang: Python Description : Kombu transport using SQLAlchemy as the message store This package enables you to use SQLAlchemy as the message store for Kombu. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019133215.18114.57279.reportbug@localhost6.localdomain6
Bug#645899: ITP: nose-exclude -- Exclude specific directories from nosetests runs
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: nose-exclude Version : 0.1.5 Upstream Author : Kurt Grandis kgran...@gmail.com * URL : http://pypi.python.org/pypi/nose-exclude * License : LGPL Programming Lang: Python Description : Exclude specific directories from nosetests runs nose-exclude is a Nose plugin that allows you to easily specify directories to be excluded from testing. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019132048.15268.25630.reportbug@localhost6.localdomain6
Bug#645897: ITP: nosexcover -- Add Cobertura-style XML coverage report to nose
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: nosexcover Version : 1.0.7 Upstream Author : Chris Heisel ch...@heisel.org * URL : http://pypi.python.org/pypi/nosexcover * License : BSD Programming Lang: Python Description : Add Cobertura-style XML coverage report to nose A companion to the built-in nose.plugins.cover, this plugin will write out an XML coverage report to a file named coverage.xml. . It will honor all the options you pass to the Nose coverage plugin, especially --cover-package. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019131733.14776.53407.reportbug@localhost6.localdomain6
Bug#645901: ITP: lettuce -- Behaviour Driven Development for Python
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: lettuce Version : 0.1.33 Upstream Author : Gabriel Falcão gabr...@nacaolivre.org * URL : http://packages.python.org/lettuce/ * License : GPL Programming Lang: Python Description : Behaviour Driven Development for Python Lettuce is an extremely useful and charming tool for BDD (Behavior Driven Development). It can execute plain-text functional descriptions as automated tests for Python projects, just as Cucumber does for Ruby. . Lettuce makes the development and testing process really easy, scalable, readable and - what is best - it allows someone who doesn’t program to describe the behavior of a certain system, without imagining those descriptions will automatically test the system during its development. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019132915.17844.14882.reportbug@localhost6.localdomain6
Bug#645900: ITP: mongoalchemy -- Document-Object Mapper/Toolkit for Mongo Databases
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: mongoalchemy Version : 0.9 Upstream Author : Jeffrey Jenkins j...@qcircles.net * URL : http://mongoalchemy.org/ * License : MIT/X Programming Lang: Python Description : Document-Object Mapper/Toolkit for Mongo Databases MongoAlchemy is a layer on top of the Python MongoDB driver which adds client-side schema definitions, an easier to work with and programmatic query language, and a Document-Object mapper which allows python objects to be saved and loaded into the database in a type-safe way. . An explicit goal of this project is to be able to perform as many operations as possible without having to perform a load/save cycle since doing so is both significantly slower and more likely to cause data loss. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019132349.17572.35255.reportbug@localhost6.localdomain6
Bug#645901: ITP: lettuce -- Behaviour Driven Development for Python
2011/10/19 Gergely Nagy alger...@balabit.hu: * Package name : lettuce FYI, an RFP with some work already done exists in #587852. You might wish to merge the two, and see if any of the work done in the past can be reused. Thanks for spotting this. reportbug failed to get the info from the BTS and I guess I didn't search hard enough beforehand. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capfutkbcz2e4pcdbrrpfjciauthepvvtxfozakncautofwm...@mail.gmail.com
Bug#620018: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
2011/4/18 Clint Adams cl...@debian.org: On Sun, Apr 17, 2011 at 11:29:07PM +0200, Soren Hansen wrote: This, even more than your constant lecturing on Debian policy, frankly pisses me off. If you have something to say, at the very least have the guts to say it in public, otherwise this collaboration ends right here. I find it refreshing that you are flouting the Ubuntu Code of Conduct so spectacularly. The Ubuntu code of conduct doesn't say that you have to put up with whatever other people throw at you, nor does it say that you cannot express your dissatisfaction with things. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin9mlczrsv-xnae-dgno8yct7g...@mail.gmail.com
Bug#620018: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
2011/4/18 Thomas Goirand tho...@goirand.fr: On 04/18/2011 05:29 AM, Soren Hansen wrote: 2011/4/16 Thomas Goirand tho...@goirand.fr: On 04/16/2011 01:32 PM, Lucas Nussbaum wrote: On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: What the state of collaboration with the upstream packagers? Replied more extensively privately to that one. This, even more than your constant lecturing on Debian policy, frankly pisses me off. What are you referring about for the policy? I've lost count of the times you've tried to lecture me on what is forbidden, how this or that absolutely must be, etc. Even if you were always correct, it's extremely frustrating and disrespectful that you always assume ignorance. I'm well aware that all our executables should have man pages. I'm well aware that we can't ship a patched ajaxterm in our packages. I'm well aware of what should go in a package's description. I'm well aware of the meaning of a dependency vs. a recommended package. I also have a pretty good idea which of those things are blockers (like, say, shipping a patched ajaxterm instead of using the system one) and which ones aren't (e.g. a missing dependency). I consider myself a rather experienced packager, but I feel you're treating me like a rookie packager who as never read the Debian Policy. All I've been fixing aren't *my* lecture of the policy, but the ones of *lintian*. There's no way I'm going to upload something in the Debian archive if lintian warns me about anything. That's fine. Making the package lintian is a great goal! It really is. Personally, I subscribe to the idea that perfect is the enemy of good enough. Had I spent a couple of extra days fixing every tiny little detail about the packaging, there'd 27 other bugs in OpenStack itself that wouldn't have been fixed. That doesn't mean that I don't know that there's more work to be done, just like I know the same is true for OpenStack. At the end of the day, I need to decide what is more critical. Our packages worked, and aside from not cleaning up very thoroughly after themselves on removal, I don't think any of the issues with the packages would be considered RC problems. Now, you are telling 2 things that are opposing each other. You are saying that my constant lecturing on Debian policy above, and below that you need more discussions about my proposed merges with you. Most of my changes are to be policy compliant. So, please choose one of the two and stick to it. most being the operative word. You've proposed a bunch of changes, all of them in the same branch. You've asked me to review and pull that branch. I've found changes I disagree with, so I ask you to fix them before I pull. I'd be happy to review and merge your changes piecemeal if you would simply propose them that way. Also, even though I asked you not to, you went and rebased your branch, so I had to start over with my review. That cost me quite a bit of time. If you have something to say, at the very least have the guts to say it in public I did. What I added privately to Lucas was mostly that I had bad feelings for the future, If you think there are problems with our collaboration, *we* are the people you should be discussing with. How else are we going to address it? because of reactions like this: otherwise this collaboration ends right here. which I wanted to avoid, knowing already how quick you can be to react. Admittedly, I get upset and extremely frustrated when people have issues with me or my work, but instead of confronting me, discuss it with other people. It's exactly how our collaboration started (instead of discussing changes with me, you posted on debian-devel to find other people who wanted to help fix my work). It's disrespectful and it's frustrating that we can't move past that sort of workflow. What I wrote as well, is that it seemed to me that Debian was not your priority. Am I wrong with that? I'm not sure how to answer that. Getting Openstack into Debian is on my list of goals. It's not at the top, because, you know, there can only be one thing at the top. I'm not sure whether that amounts to a yes or no to your question. But in short: my patches were not pulled, and I hope to get more feedback and reactivity from upstream packagers in the future. It would be quite helpful if you'd either a) follow the same process as everyone else and submit a merge proposal when you have something ready for review or at least b) let me know whenever you expect me to review your stuff. I did b), multiple times, on both IRC and email. You agreed on the discussed changes, which is why I didn't get why my proposed changes were not pulled. Because I disagree with some of them, and you've proposed them as one, great big branch. Every once in a while, I've gone and looked and have given you feedback. I agree I had the feedback 2 weeks ago, yes. I can even add that I was quite happy to discuss my changes with you. But that's it, it ended
Bug#620018: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
2011/4/18 Thomas Goirand tho...@goirand.fr: As for the fact that you had to release it with a schedule date, I *guessed* it myself. Only, saying it explicitly would have helped communication. Sorry, I don't understand what you're saying here. most being the operative word. You've proposed a bunch of changes, all of them in the same branch. Can't you just pull each individual patches that you feel ok with? Is it simply not technically possible with bzr? Short answer: no. Longer answer: Of course it's possible to extract individual patches and apply them elsewhere, but it's tedious, manual and throws away history. We bzr users care deeply about history :) Or is it that with bzr, you can only do a big merge of a given branch? That's the common workflow. So, in the future, I should do one branch per proposed merge, for each individual topic, right? That's really not convenient, It's really not very complicated. bzr branch trunk some-branch-name, hack, bzr push lp:~soren/nova/some-branch-name. Done. but I can do that if it is a bzr requirement, so that we can work faster this way... That would be great, thanks. Also, even though I asked you not to, you went and rebased your branch, so I had to start over with my review. That cost me quite a bit of time. I did it, because I thought it would *ease* your work, with each individual patch being one a single commit, so that you would cherry-pick the one that you would feel ok with. Now, I do understand that doesn't fit the work-flow of bzr, and that I have to deal with so many small branches. Right? Branches are by far the most convenient way to provide patches, yes. That's how we handle everything else in Openstack. I do now understand what you want/need. Many tiny little branches. I'll do that in the future. I hope you can bare with that (first and last) big one. Yeah, I think we're pretty close on that one now. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=y0b6joSWtq4+LCRnr=qg+jep...@mail.gmail.com
Bug#620018: Openstack Compute nova, Cactus release, Squeeze built available in our private repo
2011/4/16 Thomas Goirand tho...@goirand.fr: On 04/16/2011 01:32 PM, Lucas Nussbaum wrote: On 16/04/11 at 10:43 +0800, Thomas Goirand wrote: What the state of collaboration with the upstream packagers? Replied more extensively privately to that one. This, even more than your constant lecturing on Debian policy, frankly pisses me off. If you have something to say, at the very least have the guts to say it in public, otherwise this collaboration ends right here. But in short: my patches were not pulled, and I hope to get more feedback and reactivity from upstream packagers in the future. It would be quite helpful if you'd either a) follow the same process as everyone else and submit a merge proposal when you have something ready for review or at least b) let me know whenever you expect me to review your stuff. Every once in a while, I've gone and looked and have given you feedback. If you expect more than that, I suggest you discuss it with me instead of being passive aggressive in other fora about it. It hasn't been great so far, I agree. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimD�pwovt=ZZ5O=trqdr-bv_...@mail.gmail.com
Bug#588284: ITP: python-gflags -- Python implementation of the Google commandline flags module
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@ubuntu.com * Package name: python-gflags Version : 1.3 Upstream Author : Google Inc. opensou...@google.com * URL : http://code.google.com/p/google-gflags * License : BSD Programming Lang: Python Description : Python implementation of the Google commandline flags module GFlags defines a *distributed* command line system, replacing systems like getopt(), optparse and manual argument processing. Rather than an application having to define all flags in or near main(), each Python module defines flags that are useful to it. When one Python module imports another, it gains access to the other's flags. It includes the ability to define flag types (boolean, float, interger, list), autogeneration of help (in both human and machine readable format) and reading arguments from a file. It also includes the ability to automatically generate man pages from the help flags. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100706211026.3208.74435.report...@lenny.linux2go.dk
Bug#500716: Status of ITP: opennebula
On Tue, Apr 13, 2010 at 09:39:41PM +0200, Damien Raude-Morvan wrote: I'm looking for status of Debian OpenNebula packaging effort. I was working on it at some point, but my job responsibilites changed, and I couldn't spend time on it anymore. - Is there an $VCS somewhere with current Debian package ? There's the package in Ubuntu. I think that's the current best bet. I have some code lying around for 1.4 that I never finished enough that I wanted to get it sponsored into Debian, so it just went stale. I can try to dig it out from the depths of $HOME/src somewhere. - Is https://launchpad.net/opennebula dead ? (no upload since 2009-10-27) That's probably due to the fact that upstream moved their VCS to git. I've added a new code import for that, it should be pulled soon. Thanks for the nudge. I would like to give a hand. Any help would be greatly appreciated. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ signature.asc Description: Digital signature
Bug#576310: ITP: python-cloudservers -- Python bindings for Rackspace's Cloud Servers API
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@linux2go.dk * Package name: python-cloudservers Version : 1.0a5 Upstream Author : Jacob Kaplan-Moss ja...@jacobian.org * URL : http://pypi.python.org/pypi/python-cloudservers/ * License : BSD Programming Lang: Python Description : Python bindings for Rackspace's Cloud Servers API Python library for interacting with Rackspace's Cloud Servers, as well as a CLI tool. They both implement 100% of the Cloud Servers API. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100402205852.18189.15377.report...@lenny.linux2go.dk
Bug#555006: ITP: libcloud -- a unified interface to the cloud
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@ubuntu.com * Package name: libcloud Version : 0.1.1~git20091107 Upstream Author : Alex Polvi po...@cloudkick.com * URL : http://www.libcloud.org/ * License : Apache2 Programming Lang: Python Description : a unified interface to the cloud libcloud is a pure Python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. . libcloud was originally created by the folks over at Cloudkick, but has since grown into an independent free software project licensed under the Apache License (2.0). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554048: ITP: python-mhash -- Python bindings for libmhash
Package: wnpp Severity: wishlist Owner: Soren Hansen so...@ubuntu.com * Package name: python-mhash Version : 1.4 Upstream Author : Gustavo Niemeyer gust...@niemeyer.net * URL : http://labix.org/python-mhash * License : LGPL 2.1+ Programming Lang: C, Python Description : Python bindings for libmhash python-mhash is a comprehensive Python interface to the mhash library, which provides a uniform interface to access several hashing algorithms such as MD4, MD5, SHA1, SHA160, and many others. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451355: ITP: libgfshare -- library and utilities for multi-way secret sharing
On Fri, Nov 16, 2007 at 10:31:06AM +, Simon McVittie wrote: I already packaged this in Ubuntu. Feel free to adopt it for Debian. Having looked at the Ubuntu packaging, I'm somewhat concerned about it - it seems you don't have the changes I made in upstream bzr to make gfsplit cryptographically safe. No, I wasn't aware of such changes. The patch to gfcombine to support - as meaning standard output looks reasonable, but I'm not sure what it's doing in Ubuntu but not upstream... perhaps we could get that in 1.0.3. The patch is: The patch should definitely have been sent upstream. My apologies. I wrote it while on a train, and when I got near internet access again, I had forgotten all about it. I suck. although I'd be inclined to change it to just use stdout instead of fdopening STDOUT_FILENO, Makes sense. I can't remember why I did it that way, tbh. and make the indentation consistent (the rest of the package consistently uses 2 spaces, the else clause in the patch has a tab). Good catch. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
Bug#451355: ITP: libgfshare -- library and utilities for multi-way secret sharing
On Thu, Nov 15, 2007 at 10:02:46AM +, Simon McVittie wrote: If anyone's interested: I have vague plans to write a FUSE filesystem that works like a cross between gfcombine and unionfs, and the upstream author has told me that Søren Hansen http://warma.dk/blog/ has similar plans. Right. I'd say I'm 70% done. I want to integrate it with hal, which turned out to be a bit tricky, but I know where I'm headed. The code is a mess right now, but I'll put it in a bzr branch somewhere when I get it cleaned up a bit. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
Bug#451355: ITP: libgfshare -- library and utilities for multi-way secret sharing
I already packaged this in Ubuntu. Feel free to adopt it for Debian. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
