Bug#588857: ITP: python-flufl.enum -- A Python enumeration package
Package: wnpp Severity: wishlist Owner: Barry Warsaw * Package name: python-flufl.enum Version : 3.0.1 Upstream Author : Barry Warsaw * URL : http://launchpad.net/flufl.enum * License : LGPLv3 Programming Lang: Python Description : A Python enumeration package This package is called `flufl.enum`. It is yet another Python enumeration package, but with a slightly different take on syntax and semantics than other such packages. The goals of `flufl.enum` are to produce simple, specific, concise semantics in an easy to read and write syntax. `flufl.enum` has just enough of the features needed to make enumerations useful, but without a lot of extra baggage to weigh them down. This work grew out of the Mailman 3.0 project and it is the enum package used there. Until version 3.0, this package was called `munepy`. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712200744.2336.90532.report...@lessons.wooz.org
Bug#588858: ITP: python-flufl.i18n -- A high level API for internationalization
Package: wnpp Severity: wishlist Owner: Barry Warsaw * Package name: python-flufl.i18n Version : 1.0.2 Upstream Author : Barry Warsaw * URL : https://launchpad.net/flufl.i18n * License : LGPLv3 Programming Lang: Python Description : A high level API for internationalization This package provides a high level, convenient API for managing internationalization translation contexts in Python application. There is a simple API for single-context applications, such as command line scripts which only need to translate into one language during the entire course of their execution. There is a more flexible, but still convenient API for multi-context applications, such as servers, which may need to switch language contexts for different tasks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712201428.2375.62410.report...@lessons.wooz.org
Bug#752679: ITP: python-persistent -- generic persistence implementation for Python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-persistent Version : 4.0.8 Upstream Author : Zope Foundation and Contributors * URL : https://pypi.python.org/pypi/persistent/4.0.8 * License : Zope-2.1 Programming Lang: Python, C Description : generic persistence implementation for Python This package contains a generic persistence implementation for Python. It forms the core protocol for making objects interact "transparently" with a database such as the ZODB. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTquO7AAoJEBJutWOnSwa/3CMP/2wqMF5vyo1dlxjbW/GKc11e hW4UlgghvuilV7EK/KkzI96nsuMw2RXTxps9D3y5Yk+sUh5xRIcr+AdWGAiQ0lpJ iJgfz6tEg7UFRkSoRR9d0sxe7Tfq5ZycRNN4egUHWUuERlm0kqtKWWw1mCOuCa7h 9Lzw70Ans4zhYT7dAlpa2SDJBzqs3E2idiyaGJfpNaXXixb2VjnDieQrueK3TDkP mG+EPSUNOR1+njN7oBLRMMVsnAV7xAvCinCFPR5j1mTjZCAn7QS+qT26BL74lWa4 Zw0dDcMh8SW87XsGsz2j0ELpZ7/dS0PAyYpb3o12UY23Jbwzlp/MwmCzBoB0iiA+ 97vlaX7Swm3WxuLFTSZaX/Px0Z2BZXz1h7ufWqBmU1kUvaM1VeplFX5EGnPbQooe PanvXXAEdjxbh2KHgOxvWqpexDdsAGMMKAwpyscSyd5Dq7O9PvkFNqF7QTwnNLtj ktmN2U2Ot3M1QnR7K8QMuomBEDdIeiQNZ1vuB7YLBzOSJaCt6mtsmzqfDHY8E6Pm eUaBwTme3I4elLnKLdu/Toghv77uUlbWlZ+ePJQOu+1apa4fYSN9cvfmbk7tnyge inZ6F6uLotNO6VgkLkUiik1w0CRDAyrHyYa4KBrr9HeCrg7gEtDunf4MtsPbKbfy dZoIvKXWcxT6B95rWGVr =a40U -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625145909.881.50362.report...@chemistry.wooz.org
Re: let missing-debian-source-format lintian tag be a warning!
On Jul 15, 2014, at 12:37 PM, Scott Kitterman wrote: >On Tuesday, July 15, 2014 18:12:41 Andreas Metzler wrote: >> Scott Kitterman wrote: >> [...] >> >> > It seems to me 3.0 (Quilt) is still applying patches when the >> > package is extracted using dpkg-source. Is there a way to avoid >> > that too? That's been my major objection. >> >> dpkg-source -x --skip-patches foo.dsc >> (Does not work in debian/source/options, though) > >Not adding debian/source/format gets me the same thing with less typing >(although I appreciate knowing about the option, I'd missed that before). If >that worked in debian/source/options, then I don't think I'd have a strong >reason to avoid 3.0 (Quilt). Should it though? Isn't to apply or not apply patches automatically a preference of the individual developer rather than of the "package"? Especially for team maintained packages, if you and I are on a team, you might not want it to apply patches but I might. I suppose in those cases though, teams (or even co-maintainers) can establish conventions, although it would be nice in that case to also have a --no-skip-patches option. Cheers, -Barry signature.asc Description: PGP signature
Re: let missing-debian-source-format lintian tag be a warning!
On Jul 15, 2014, at 09:07 PM, Raphael Hertzog wrote: >If quilt is the problem, aren't you more satisfied with tools like gbp-pq >that lets you avoid quilt and use (rebased) git branches to manage the >quilt series? My one experience with this was not very successful, although I'm sure it was pebkac, and yes I should have filed actual bugs if I found them (but was under a crunch at the time). IIRC, where I would normally apply a quilt patch, edit the file, and refresh the patch, I always ended up with every modification as a separate d/patches file, even though I thought I was rebasing it correctly. Oh well - I'm curmudgeonly pretty comfortable with the svn-buildpackage set of tools and workflows, which the DPMT still prefers. I need to play more with gbp and git-dpm, the latter which IIRC felt smoother. Is there any emerging consensus on which of the two git-based package development regimes is "better" or "more popular"? Cheers, -Barry signature.asc Description: PGP signature
Re: Standardizing the layout of git packaging repositories
On Aug 17, 2014, at 11:19 AM, Thomas Goirand wrote: >By the way, I try to always avoid using "master" as a branch name. This >doesn't express anything at all. +1 In the context of Ubuntu (and when it works ) I really like the approach taken for UDD branches. I can always branch the version of the package in any series, e.g. $ bzr branch ubuntu:utopic/python2.7 or if I want to get to the version of the package in proposed: $ bzr branch ubuntu:utopic-proposed/python2.7 with an alias for the most commonly requested version, i.e. the released version in the current development series: $ bzr branch ubuntu:python2.7 # gives me the utopic/python2.7 Of course, I can get the version in any other series. I can even get versions in Debian via: $ bzr branch debianlp:python2.7 or $ bzr branch debianlp:wheezy/python2.7 Obviously the details will be different with git and Debian, but I think it makes a lot of sense not to assume what 'master' might point to, but instead be explicit about the series name in the branch name. If it's possible to make a shorthand alias for the most common branch (unstable?) then that's fine too. Cheers, -Barry signature.asc Description: PGP signature
Re: Standardizing the layout of git packaging repositories
On Aug 16, 2014, at 01:15 AM, Thomas Goirand wrote: >As in, always use pristine-tar? No! The point of using git packaging is >also to be able to use upstream git repo. What about cases where upstream doesn't use git but you still want to use git for your packaging branch? Also, it makes me somewhat uncomfortable to assume that a git tag in the upstream repo will always be equivalent to their released tarball. In fact, it's often not, as is the case with Python packages containing a MANIFEST.in. -Barry signature.asc Description: PGP signature
Re: Standardizing the layout of git packaging repositories
On Aug 17, 2014, at 08:47 PM, Henrique de Moraes Holschuh wrote: >It is not meaningless in the sense that it is a widely used convention in >git repositories. > >And that's actually quite relevant. It makes more sense when you're a pure upstream, as master might be where you do all your cutting edge development, and there isn't usually a clear alternative naming scheme (e.g. code names). 'trunk' might be better anyway. But in Debian's case, all packaging work is targeted to a series, so it makes more sense to make that evident in the branch name. -Barry signature.asc Description: PGP signature
Re: Standardizing the layout of git packaging repositories
On Aug 16, 2014, at 04:28 PM, Thomas Goirand wrote: >Why?!? Is there some sort of religion around tarballs? Shouldn't it be >the same stuff that "git archive" does? If it isn't, why is this the >case? Shouldn't one be able to use what's in the Git repository anyway? >Why can't it be fixed? Aren't we supposed to "build from source" anyway? >Isn't the upstream git repository the "preferred form for modification", >closer to what someone should be using when contributing upstream? Why >is it the case that upstream prefers that we use something generated >from his git repository? Shouldn't all what upstream generates in the >release tarball also done by the Debian package build anyway? This all assumes very specific upstream release workflows. It might be fine in many cases, but there's such wide variety in upstream development processes that a maintainer would have to know much more about how upstream releases than they do now. I think about the typical PyPI package. I really don't have to know much about how upstream generated the tarball on PyPI (*and* signature/checksum), just that they magically did so. The upstream tarball is a shorthand and a very convenient abstraction for the upstream's magic - and perhaps not easily discovered - release process. >So yes, please do generate orig.tar.xz out of PGP signed tags, and do >Debian git-buildpackage based on tags repository, using the upstream git >repository as source. That's the correct technical thing to do, and you >wont regret it! As an upstream: please accept progress and convenience. As Debian developers, I think we generally shouldn't be dictating best practices to upstreams. Let them do whatever is most comfortable to them and let them concentrate on making good software! Upstreams have a lot more concerns then how well their branches fit into Debian's packaging machinery. Sure, most upstreams are pretty Debian friendly, but they might have to worry about how releases get made for vastly different OSes (i.e. not even Linux) so Debian can be just a blip for them. I.e. nice if they can make our lives easier but don't count on it. For better or worse, the tarball is the abstracted medium of exchange between upstreams and downstreams, and it makes good sense to have that. (I'm not arguing against using an upstream git tag when it *does* all work nice and smoothly, just saying you can't count on it, and should force our workflows onto upstreams'.) Cheers, -Barry signature.asc Description: PGP signature
Bug#758670: ITP: lazr.smtptest -- framework for testing SMTP-based applications and libraries in Python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: lazr.smtptest Version : 2.0.1 Upstream Author : lazr-us...@lists.launchpad.net * URL : https://launchpad.net/lazr.smtptest * License : LGPL Programming Lang: Python Description : framework for testing SMTP-based applications and libraries in Python This is LAZR smtptest, a framework for testing SMTP-based applications and libraries. It provides a real, live SMTP server that you can send messages to, and from which you can read those test messages. This can be used to ensure proper operation of your applications which send email. lazr.smtptest is a test dependency of GNU Mailman 3.0 This will be team maintained within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT87C1AAoJEBJutWOnSwa/SQ4P/2r/Rr4j1nozSl6PrVGbfD9o cB9Y5vWjTmQWSpd83F9Jg+S0ssv4n5vZiBEYT7a9V4wXfK16vylTJgiEfh1IIeVc 0VsEbpTSmiPwJfBbUkojPGZA3nV6DcYfTkZsDoXcBy17Vvm394CmkEp44tY3WZI3 XulOnEBX9VUFba+rZWyAGqKNzP8RhLjmn0ekr2RriBdnXtQ+sIQZ8zPfmB1kBb+r BNkhO0yIdtNplcD7gZQQ8BHand/6Wu3inJlEIllEZgQSoa9HR7S44JSFN72bvs+v Qyii/YJGpIIqsCKc9i3hugS0gUkpM08BDoDU0EB2zyuqoCZ/ShmDNQLdhvQ7Duo+ vuXdAtIca4IBa+vUmbI1VeVWEfxF9C8pGp2d4gMmm0JpzfO29QPAswGzxVaBaqD0 tt0tofS7v2pjlyxTv9Uy9vyvSMt655B9aWSvAhAE06UKa9f0ZZRttAKdELPDhkTl +ZZf960Bkd3ieO5oom0Zjo+xN9ae6oVXYk7FrzVK0igiyWQgnGnMcH3I+5T2uQ2h Bd1buNei70j/aVi1bW0qtK0pMaZvY+PYSrWgTOH9FS/2+tooa66Rp6s3UL/pLZWZ kF42O4UxP9m51i9wPSp69Xf9gDUB1qe/VVPQ4VbxmrDqCSB4JmQwlUj3AY/PKw8U TQfd5Wl93pf91JgWvTnb =latQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819201656.4168.11274.report...@chemistry.wooz.org
Re: Standardizing the layout of git packaging repositories
On Aug 20, 2014, at 02:17 PM, Ian Jackson wrote: >I am planning to have dgit do some git-dpm'ish things, probably >actually using git-dpm. Excellent. I've been playing around with git-dpm (as described over in debian-python@) and it does a lot of nice things. There are a few glitches IMHO, but nothing insurmountable. It mostly handles the conversions between git and quilt pretty nicely - so far. OTOH, I'm philosophically aligned with the goals of dgit, i.e. having the vcs branch exactly mirror what's in the archive. >Personally, I think this is a waste of time. git's UI is appalling >but it is by far the most capable VCS in existence. Attempting to >cater to the lowest common denominator will be crippling for any new >tool or approach. Agreed on both points. :) >Will you be at Debconf ? I'm hoping to have some more handwaving >etc. about this kind of thing there. I'm hoping there will be discussions regarding vcs at Debconf (I will be there), especially among the DPMT for planning on a transition from svn to git. Cheers, -Barry signature.asc Description: PGP signature
Bug#758827: ITP: lazr.config -- ini-file format handling supporting schemas and inheritance
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: lazr.config Version : 2.0 Upstream Author : lazr-develop...@lists.launchpad.net * URL : http://launchpad.net/lazr.config * License : LGPLv3 Programming Lang: Python Description : ini-file format handling supporting schemas and inheritance The LAZR config system is typically used to manage process configuration. Process configuration is for saying how things change when we run systems on different machines, or under different circumstances. This system uses ini-like file format of section, keys, and values. The config file supports inheritance to minimize duplication of information across files. The format supports schema validation. This package will be team maintained by DPMT. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9kSkAAoJEBJutWOnSwa/R78P/RB0pSbzGgDO3CebxG17w4el BEGEJS3Vigfxe/74ZBUNS2fmdSOGxaXNjS5u1Tr70lCNMCtSj6W7tIBh54vyoc+s udgePOJZikvYaKcyfwSCk9lEwtrFcBqTpPLXiYH4mmaSNYB+3yr18nz2MSZ6eShX JeXNyxCNj/W7w7a656iCKbA8nIrKjQfnag9C/kfDZCmelCV/gxilYUF0rOBKpuql GORHMPkpcsGbIs+LPRYs93giokb95nPmLQdnLQ5VxzPb17cvS78som413YsZGPYP 8pui5anNR6uBIj+dKBjPoyodOcrpDhq6NG3fA4dyZCdxOmRgGq5XaeJAziv8cj8i NlYDOt7yJJeVR9MjdmnI79HuqP3c6ywEW23okAv5ymcLayLmXzG+osOp3UoLeVWS iJ1ix77M7TGIs4T5IkjIZ9myZEVsZMAMgjVtCS5bLil2KTjE4sYGcKSwmINWOQRQ VVHjtByR8MljtXxFUTUdpFeCU2efx9oH3CPMgMPxEZQ6MC2tNzeRPyfjYKnJYg0u I1BklA5gBf4dZiqdjedvRico2zDocc9YEwtS5f/ehpqCO2Xf2g1PqUAzXo1s1Ac6 01Qle3G91CAUriQsjaAEtdL+UH+7DzGsSFPuEy2eZANrdFBYoHP08kve60W3RwaD NDwM95Cy2l0vRtvBJawe =VwHc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821191239.890.52662.report...@chemistry.wooz.org
Bug#758828: ITP: lazr.delegates -- easily write objects that delegate behavior
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: lazr.delegates Version : 2.0 Upstream Author : lazr-develop...@lists.launchpad.net * URL : http://launchpad.net/lazr.delegates * License : LGPLv3 Programming Lang: Python Description : easily write objects that delegate behavior The `lazr.delegates` package makes it easy to write objects that delegate behavior to another object. The new object adds some property or behavior on to the other object, while still providing the underlying interface, and delegating behavior. This package will be team maintained by DPMT. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9kYhAAoJEBJutWOnSwa/0aIP/1LUmseitb3YSHqUdIcFwgwu DAd/HnfkGQZBngw8gvdXxZgptnuIaXnNT1mTUnTW0Db/yIo+4zHVp+qKrk1rrPky omhQ7H3fIddBVQmbH8wY/3Vr4g/eBL8kpkv0Afb1GFmoirHM+IkSo39o1cb2rafF z3EDzoW5T8kNdz+9xgCIENYImEwAXVu1NKSnHWx+hwn0EQmNXyNN6MflGfdVvGjr kOsv9N8uwRINQeX37tM6wEBvL/jnCeysdzZ1Obg/7+c55Q9X6mgHFKCahgd2dKw1 TX1oYLuZFFoHVxqZYrvxCC2FXPuuubMKuT6FWWGjXaEAqEesdVyw3DUBTJ16F6Wh LKqKyCCHjVhio6u6mIZ1pSyLaIZB1PsPSDyZET5ETp3nGKTODgYz+cFZSBfO4Cck tbDl1tRzhhrq5eC7coa002xmlKbvlr6KvfClNdGBQzZcWUqD5INfi9QY815TZt1X ettH5+rGjNSorxVcugT0OH2IxtJNYijqx2+1bczC2Ox2dIC12Agr1E2GCSdAtHJS W206Mu2xME6GFUPPvDIka1R3x/nJYO+dvZQpUVADsD37otAQ8Ju0g9LY4e+SiMUn EAo/I7BtuNeQUD7rOCZDGUrBtezhZDMxC4fqHI9Xc6kdKe+8WczwCO6MU6uDYE/g HE7PX59YcFAQ2syA4oUH =ofbm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821191859.956.32864.report...@chemistry.wooz.org
Re: Standardizing the layout of git packaging repositories
On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote: >git-buildpackage's gbp pq system is what I use. I believe git-dpm is more >complicated and comprehensive, but gbp pq is simple enough in its >operations that it doesn't take long to wrap your mind around it. git-dpm seems pretty easy to use as well. YMMV, but ultimately I think both helpers achieve the same goals. Over in debian-python@ we're having some good discussions related to moving the Debian Python team over to git, and many folks have contributed useful stories and experiences. I'm beginning to think that what we want is for gbp and git-dpm to interoperate, such that any individual maintainer can use whichever tool they choose, but would still allow the team to adhere to consensus recommendations, so there's no guesswork involved. E.g. the ultimate artifacts would end up being the same, regardless of whether you used gbp, git-dpm, or plain vanilla git + quilt. One example of a superficial differences is the tag names used by default. They're different between the two helpers, but really needn't be. -Barry signature.asc Description: PGP signature
Calling all git-loving Pythonistas
Do you like working on Python packages but are using collab-maint (or other) instead of the Debian Python team's repo because you prefer git over svn? Do you pine for the day when you can rejoin the DPMT or PAPT and still satisfy your git cravings? :) One of the decisions at Debconf14 is that the Debian Python team will transition to git... eventually. We're still in the learning, experimenting, and discussing phase, so we're not yet ready to do a wholesale conversion. But if you are currently using git to maintain your Python packages, we want to hear from you! I encourage you to re-engage with the team via the debian-python@ mailing list, and help us effectively transition to git. Some of the things we're now trying to decide include which of the various popular regimes to adopt, e.g. gbp-pq, git-dpm, or dgit. Other topics of discussion are outlined in Stefano's summary of the DC14 conversations: https://lists.debian.org/debian-python/2014/08/msg00159.html There are other threads in the archives, so please do read up on our discussions to date, and come over to the debian-python list to give us your suggestions and feedback. Cheers, -Barry signature.asc Description: PGP signature
Re: Trimming priority:standard
On Sep 12, 2014, at 07:18 PM, Jakub Wilk wrote: >I'm looking forward for systemd-mta. It's inevitable. ;) http://catb.org/jargon/html/Z/Zawinskis-Law.html -Barry signature.asc Description: PGP signature
Re: Automating snapshot.debian.org downloads
On Oct 22, 2014, at 03:02 PM, gregor herrmann wrote: >debsnap, in devscripts. >gbp-import-dscs --debsnap, in git-buildpackage I've also been working on this script (with help from tumbleweed) for similarly importing history using debsnap into git-dpm: http://anonscm.debian.org/cgit/users/barry/import-dscs.git/ Cheers, -Barry signature.asc Description: PGP signature
Re: dgit and git-dpm (was Re: Standardizing the layout of git packaging repositories)
On Oct 29, 2014, at 01:47 PM, Ian Jackson wrote: >I got the impression that sbuild is winning over pbuilder BICBW. Especially now that bug #607228 has been fixed! Cheers, -Barry signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote: >Here's the draft: Thanks for getting this started. I think it will help considerably to get some standardization here. I would think that as more teams adopt git, they will eventually just refer to DEP 14, perhaps with some additional team-based deviations if necessary. One question: when this gets adopted, will individual maintainers or teams have to know which of the git packaging helpers a particular repository is using? IOW, what happens if I were to use gbp-pq on a package that someone else had used git-dpm on? Do we need some kind of convention to detect which helper is being used? I wouldn't want to restrict choice by defining a standard Debian-wide (but it's okay within the context of a team). I just want someone who walks up to a git repo to at least easily know which tools to use. >Vendor namespaces >- > >Each "vendor" uses its own namespace for its packaging related >Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and >so on. My question is whether the vendor namespaces are overkill for the majority of packages, where there probably will be just one vendor (i.e. Debian). Should DEP 14 allow for a simplified layout such as master, pristine-tar, upstream when there is no other vendor involved? Allowing for master as an alternative to debian/sid or debian/master might simplify the common case. However, I'll also note that for pycurl, I'm currently using master to be the Debian unstable branch, and ubuntu to be a small set of deltas on top of that, for the current Ubuntu development series. If I needed to support older releases in either distro, then debian/wheezy or ubuntu/utopic would be good branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) > QUESTION: some people have argued to use debian/master as the latest > packaging targets sometimes sid and sometimes experimental. Should we > standardize on this? Or should we explicitly allow this as an alternative? It makes some sense to allow this as an alternative, but then my question about using 'master' as an even simpler alternative for the common case should also be asked. >When releasing a Debian package, the packager should create and push >a signed tag named `/`. For example, a Debian maintainer >releasing a package with version 2:1.2~rc1-1 would create a tag named >`debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with >version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should >point to the exact commit that was used to build the corresponding upload. Agreed. Tag namespaces certainly make a lot of sense. >If the Git workflow in use imports the upstream sources from released >tarballs, this should be done under the "upstream" namespace. By default, >the latest upstream version should be imported in the `upstream/latest` >branch and when packages for multiple upstream versions are maintained >concurrently, one should create as many upstream branches as required. Similarly, is 'upstream' okay for the upstream branch? It's a little simpler than upstream/latest, especially if you don't anticipate importing an other upstream branches. Again thanks. After Jessie is released, I hope to restart this discussion over in Debian Python, for that team's transition to git. Cheers, -Barry signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 12, 2014, at 10:02 AM, Raphael Hertzog wrote: >I don't know. My long term hope is that in this process we will get to a >situation where: >- either the tools are sufficiently interoperable that we don't have to > care about this >- or one of tools emerges as standard supporting all the important > workflows that people are using I think we should strive for #1 for now and see if #2 emerges. >I am rather opposed to this because it because it doesn't separate clearly >the namespaces for the upstream development and the namespace for the >Debian packaging. I still think you could get away with simpler names for most cases, but it also seems fine to establish these namespaces. I mention it because over in Debian Python we've been experimenting with the migration to git, and if we're going to continue then I think it's useful to align with this DEP. It'll mean renaming some branches in the experimentally converted repos, but that's should be okay. >> for the current Ubuntu development series. If I needed to support older >> releases in either distro, then debian/wheezy or ubuntu/utopic would be good >> branches to use. (Or IOW, what's the equivalent of debian/sid for Ubuntu?) > >I was wondering that as well. For Ubuntu, it probably makes sense to use >ubuntu/master because the latest development release regularly changes and >it's not a good idea to alway update the branch. Actually, Ubuntu does have a 'devel' channel for rolling releases, and I believe it's guaranteed that this will always point to the current, in-development version. E.g. right now it points to vivid. So I guess ubuntu/devel makes the most sense here. >Or maybe we recommend "upstream/latest" by default but allow "upstream" >alone in the case when there are no other upstream branches tracked ? +1 Cheers, -Barry signature.asc Description: PGP signature
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Nov 12, 2014, at 09:27 AM, Matthias Urlichs wrote: >Then we should either remove the paragraph entirely, or at least mention >the danger of bit rot and that it's unwise to rely on being able to recover >the tarfile (long term). Because the vast majority of upstream Python packages are released as tarballs on PyPI, I have recommended that we continue to use pristine-tar for debian-python packages maintained in git, even with the oft-mentioned problems with pristine-tar. (Which FWIW, I have never seen *in practice*, though I know others have.) Other team members don't want to use pristine-tar for various reasons, and I think it makes less sense if upstream doesn't release on PyPI. >Jonathan Dowland: >> On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: >> > Personally I wouldn't use anything other than debian-only repos, at >> > least for those where I have a choice. I also actively avoid >> > contributing to packages that don't use such repos. >> >> And I'm the exact opposite. > >FWIW: Me too. Debian-only is, to me, quite annoying, and a remnant of a >workflow that was once a necessity (with CVS/SVN). Not so with git. +1. On Ubuntu, we had sourceful branches with UDD (bzr-based Ubuntu Distributed Development). It always seemed more awkward to use debian-only branches in debian-python svn branches. Playing with sourceful e.g. git-dpm is a joy. Cheers, -Barry signature.asc Description: PGP signature
Re: Bug#660842: ITP: python-gnupg -- python wrapper for the gnupg command
On Feb 26, 2012, at 12:26 AM, Evgeni Golov wrote: >On 02/22/2012 10:40 AM, Elena Grandi wrote: > >> * Package name: python-gnupg >> Version : 0.2.8 >> Upstream Author : Vinay Sajip >> * URL : http://code.google.com/p/python-gnupg/ >> * License : BSD >> Programming Lang: Python >> Description : python wrapper for the gnupg command > >What's wrong with >python-gnupginterface - Python interface to GnuPG (GPG) >python-gpgme - python wrapper for the GPGME library >python-pyme - Python interface to the GPGME GnuPG encryption library > >What are the benefits of python-gnupg? The homepage doesnt tell any, >neither does the description :) Another important benefit is that python-gnupg supports Python 3[*], while I think the last upstream change to python-gnupginterface predates Python 3 by many years. Please do create the python3- version of the package. This page may provide some helpful guidelines on how to do this: http://wiki.debian.org/Python/LibraryStyleGuide I also hang out on #debian-python and am willing to help and/or answer questions. Cheers, -Barry [*] 3.1 according to the documentation, but 3.2 according to the Cheeseshop page. Given the recentness of the last activity, and knowing Vinay, I'm willing to bet it's 3.2 compatible and wouldn't be surprised if it even worked with the in-development 3.3 branch. signature.asc Description: PGP signature
Re: Bug#666790: ITP: python-regex -- alternative regular expression module
On Apr 02, 2012, at 09:58 AM, Tollef Fog Heen wrote: >This sounds like a bad name, since there used to be a regex module in >the standard distribution a few years back and there's therefore a fair >amount of documentation warning against using it. Some of us were even joking at Pycon 2012 that we should just have a revolving set of names for the regular expression module rewrites in Python: +- regex -> re -> sre -> -+ ^ | |-+ rinse-and-repeat-ly y'rs, -Barry signature.asc Description: PGP signature
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On May 11, 2013, at 11:15 AM, Scott Kitterman wrote: >Close. Because there is no aging requirement it moves much more quickly and >as a result, there's much less risk of multiple transitions getting entangled >and delayed. > >Ubuntu explicitly defines the $ RELEASE-proposed pocket as 'not meant for >humans'. It's only for building/automatic testing. > >A nice side effect of this moving faster is that the Ubuntu release team >doesn't pre-coordinate transitions. > >It's very close to what Debian has, but that small difference has a large >impact. Which suggests that it might not be a big step for Debian to take -- technologically at least. The social distance might be greater. But Scott's right that it's been a *huge* improvement in the process and it would be wonderful in Debian too. For anyone interesting in pursuing this further, I suggest contacting Colin Watson, who I think did most of the development to make this possible. -Barry signature.asc Description: PGP signature
Re: Debian systemd survey
On May 23, 2013, at 02:17 PM, Josselin Mouette wrote: >I’m not criticizing the fact that upstart comes from Ubuntu. I disagree >with the idea of having Ubuntu as the sole origin of innovation in the >project. It gives bad habits to both Debian and Ubuntu if the natural >thing to do to make things happen in Debian is to make them happen in >Ubuntu first. For a comparable innovation, I’m thankful to Canonical for >making multiarch happen, but the fact that we have waited for Ubuntu to >make it happen is the symptom of a Debian problem that needs solving. I don't think it's necessarily a bad thing for Debian and Ubuntu to have this kind of symbiotic relationship. Maybe from a Debian point of view, it shouldn't be necessary, but given the current realities of differing release schedules, goals, focus, and resources, where such an arrangement exists, I think it can - and should - be used for mutual benefit. This of course requires good coordination between the parties involved in both distributions, and motivated people in both camps that want to strengthen collaboration. Of course, some folks will only have feet in one or the other, and that's fine too. Some recent examples include transitions we've seen in the Python world. The push for dh_python2, the push for Python 3 support, and the transition to newer versions of the interpreter are all great examples (IMHO) where Debian and Ubuntu worked together to come to some semblance of consensus, and where Ubuntu, by benefit of its timed release schedule was able to be more aggressive in adopting some of those transitions. It was also able to experience and alleviate some of the pain first too. But this was *always* done with the goal of ensuring those changes would get pushed back into Debian when the time was right. In such cases, the assistance, insight, expertise, resources, and feedback of experienced Debian developers was crucial. It's usually (but not always) easier to get changes that appear in Debian first, migrated into Ubuntu. IME, it's often harder to get changes from Ubuntu into Debian. I think there's ample opportunity to help make this barrier lower on both sides of the pond. Some of the hurdles include: - Team based vs. individual maintainership. In Ubuntu, no one person (or group of people) maintains any package. There's a strong sense of team for maintaining packages. This has an advantage in that important updates need not block on availability, workload, vacations, etc. of individual maintainers (not that it can't block on other reasons). In Debian, teams like PAPT and DPMT do help with this. - Membership differences. I am currently sitting on the Ubuntu Developer Membership Board, and I am in the final stages of my DD application. Applying for DD was way more thorough than achieving core-dev in Ubuntu. Now, this may or may not be a good thing, but one of the key things that the DMB is addressing is how to streamline approval for DDs. It should be fairly clear that a DD has the requisite technical expertise to package things for Ubuntu, so the initial interaction with the DMB can (mostly) accept that as a given, and thus explore other requirements of Ubuntu membership. Hopefully (and I'd like to hear if otherwise) this means that a DD who wants to also contribute to Ubuntu, should be able to get the needed permissions fairly quickly and easily. In Debian, it would be nice if the process were made easier, or more inviting for Ubuntu developers[1]. - Tool mismatches. I just wish it were easier to build packages for both Debian and Ubuntu, but the tools chains are sufficiently different that it's difficult to switch your (well, *my* ;) brain into Debian mode from Ubuntu mode and vice versa. Part of it is dealing with Ubuntu Distribute Development (UDD), which I'm very comfortable with, and which gives me a source-full checkout of a package (debian/ + unpacked upstream) all managed in a DVCS branch. I can grab the source for any version of any package on any release of Ubuntu (and actually, Debian too!) through Launchpad[2], so it's easy to make a change, do merges from Debian or upstream, build it locally, test it, and upload it. I personally find the Debian tools (svn instead of a dvcs, debian/ only directory) harder to deal with, but maybe that's just me. I've said before that as much as I dislike git, if Debian had something like UDD+bzr but git based and more interoperable with quilt packages, I'd use it. Also, I do think that Ubuntu's source-only uploads are a win. PPAs are nice too, as are the new -proposed pocket for the in-development release. - All is not roses in Ubuntu-land though. When uploads to Debian are delayed (e.g. because of release freezes), then Ubuntu can get ahead of Debian in ways that are more difficult to untangle. Ubuntu's auto-import from Debian gets blocked whenever a package has an -NubuntuM version number. These ta
Bug#712881: ITP: python-enum34 -- support for enums (backport of Python 3.4's enum package)
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-enum34 Version : 0.9 Upstream Author : Ethan Furman * URL : https://pypi.python.org/pypi/enum34 * License : BSD Programming Lang: Python Description : support for enums (backport of Python 3.4's enum package) PEP 435 describes the new enum package for Python 3.4. enum34 is a backport of this package for older Pythons. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRwwOhAAoJEBJutWOnSwa/y94QALh+XU4J5kQ9pgpccGeuIpbm 6I7azhBnMvpojuJrcQCulGqs4EQ1sPPpCvEU6MWrwt30d5nmacEbVEBJuOQK1F9/ 4xDtprAmHrbZ7OkBfMrumj6+HSyO3yNTLz7VbXFeg4VdE0blIEq/fW7iFVBRMIOU BtqMLHs5fkhS+fLUJIxuByTahKnt89cdQRcfh3ntrx6oYKLX6x13dSTyE2C/Ur/M krxoVYzW8xR6q/sWBcKaT3btvlbfdmopu95WRGXfDnVvYsqtp5SSfQR65uWWj4RW Lh5igtUw2Dq6e0oMXpDYqJZBqYLE+emqo48DikR4obAtKrOMYx1blinnWAJbobBY gg/MR9PVa2eL4f3fNSH8SPiSw6HSTEq9bJzJviD1sJsERRT3iRoETlTjtaV1gQZ6 385SR5cls9Jol+5h1/oX/2E72SasNvq3dBKXzM/h5/KXTUjOY7pkVqzLMhBnDXHn ohu9u/x7gl+FBVV6KRQkLWbRbOMV7BAluidztPxHH/Iql/rsYtGw1qW5z/ZbPhiF Kbg0WOZWM8gSLCBgx2NF/31OOeFDvVIeRz9DIsdtokbpwihxq4lsyjELdXhkUEtZ HLZMVgJdO0IhFjAzo9NTgSox6jsTaucX7qAd0QVdw2Sq2E0Nwz56TyO+3IPw6HsT gxzjB31JVZPYGzYtVyEp =2FYm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130620132907.7067.97143.report...@chemistry.wooz.org
Bug#714412: ITP: python-pytest-instafail -- py.test plugin to show failures instantly
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-pytest-instafail Version : 0.1.0 Upstream Author : Janne Vanhala * URL : https://pypi.python.org/pypi/pytest-instafail * License : BSD Programming Lang: Python Description : py.test plugin to show failures instantly https://pypi.python.org/pypi/pytest-instafail/0.1.0 This is now a Build-Dep for tox. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRzhioAAoJEBJutWOnSwa/su8QALU1xf3qi9vtR6eNzcq2EUTJ rkJMEvgz4rhvI3I880DzULeOtnkdh2YWkuR8cjXxvmbh6JK/2Czbiwqbpj3cu5f3 qLVX0i/ToKQgprLEn5rYYIcopFXDVC+2dRhfwtLskiy5HtmdBlpY7UHtoCEIPMvV Z7ivblsHKH32C3p50NHcc3H6RNuv0mOYIn7D23x4dLpOZhaXFdvCa3RNfGrZTAhG hzOAIuoNc6/kBEccHJPXfY0HW6e/i1oo93aRNXNUcNrc95Xtc8DfFn0Lx6n/aMea 0Smrjm29Z8lb348/JDxJPGvRllWIw9jSwJ9apK0k1TTliQj365iSvbUEObxD2CSY orOCUHAtPC+gEC+z7hQ5T2mcbnCWydpsHtXBjktSoJ9dJaERJFpFRA1VopMpPc3z QPorj4OMIgLoo1R6STC9gOWmnZZpwi2cknDFBRGTrdzvwd/cKEc985Ed4fBUu5VZ 2gy3Vn38uANgGZko3mdeW+kNchkeRR86yyTuDky1lTxsoN5cjRzEzPrzTzX8ltmg f5O5YiOfD+UTP2J2N9GcEPFyB0eh0TPMNBwORszjmTeeiov+D+d5+4DMe90JAuTc +ofzDX6Oete5qOs8l4WK2cg5ttedGXPKkqjvgSspAf8v5Z93+nfI2MXQrV3I1vJC nxgagaCQ8Kiqh3wD6piW =Yxg/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130628231352.32597.16587.report...@chemistry.wooz.org
Bug#714636: ITP: restish -- WSGI framework/library for building resource- and rest- oriented web sites
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: restish Version : 0.12.1 Upstream Author : Matt Goodall * URL : https://pypi.python.org/pypi/restish * License : BSD Programming Lang: Python Description : WSGI framework/library for building resource- and rest- oriented web sites Restish is a simple to use, lightweight WSGI web framework and library with a strong focus on resources, request/response, URLs and content negotiation. Restish has very few dependencies and does not assume any particular templating or database engine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJR0YN5AAoJEBJutWOnSwa/Dt4P/0OHuqK9xckZMciXSK0n3TDS PyiC8Wu84X5XE2baVSKjOhzCrMMutYgHvJDGwgmWkuQg9Kg9HtfFKk/VQHyh3cq+ ouHuO3KN19Ifu1KiICPMuwwzIexLkv9TJ5Yp4s/MrcW1vEc04G0B7XBbk6VUuINu 8N+T/hAOg3VayXOsruBKMEJHJE6RrPnadvIVhwmJB8rKC60+uzlNB58XzFNzRjJQ 4edwhvcCN8hfGrAp5FyeXH5Q5fEaFg0SfhZmM/T5cO6YRgO6NjSBMqlkhZ2I0n1w p3yt7oYZ9KHojQu8kRZqYpi19551+IcWf+YgtWApgTfCu+WJp670ebltrz8q19m4 EzUPzJrsjhzxfAQCYU6F1+J9YafBxSykwS7ZjKs4EcuUTCPhj+hYKnO4qCIHG8YV qi3KGO7eOZldr8EOs364CZ8MCpUbjkG5Baq+kWlJyujOZqibAJZ4N8/XM6JQ0TWJ Jirp6pRqsNOcr5kMA3LdKCRB3HZPr5M9hrmMgPgV1tU5FisDd9DMPoA0oi8lIeHb kGpnC11lcdcjuQ5sWcHtlLTPxnajyJDMyfdx0X5cqS+LEC2vAmeAAZEFbQJVQdgo Vt3ryXTrn25gfyZry+ZS1BSnRHIVgkPPNx/lO6QusV+Oo0Hr75aQNhbCYshq8zLE rbGE5JilnpKA6+W1gwg6 =+oGv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130701132619.3092.87899.report...@chemistry.wooz.org
Re: Introducing dgit - git integration with the Debian archive
On Aug 31, 2013, at 01:37 AM, Jelmer Vernooij wrote: >In the end, this meant that using UDD had some minor benefits (a richer >history, and theoretical improved merge support) I'd argue that they were more than minor benefits! >but there were a number of extra things you had to watch out for that made it >frustrating to use: manually checking sure that the branch was in sync with >the archive before using it (and giving up on UDD or prodding us if it >wasn't), It was really great when you guys added the feature to bzr to actually do this check and tell you if the branch was up-to-date or not. >making sure you pushed the right changes to the UDD branches (otherwise they >would be overwritten by the automatic importer). I learned never to push a UDD branch. I almost never had problems when I let the importer update the branch on upload, rather than try to push a branch. The downside is that there could be a lag between upload and branch import, but it hasn't really been much of a problem in practice. >Cloning one of the bzr branches can also be quite slow because of performance >issues in bzr that took a long time to fix, and because Launchpad is in the >UK, whereas there are a lot of mirrors of the Ubuntu archive. I never found the performance issues to be a hindrance, but I have a good internet connection. Besides, over time this was ameliorated by using bzr shared repos. >I always considered having the .pc/ directory checked in and the patches >applied by default for the quilt format a mistake, as it lead to tons of >spurious conflicts during merges. It's nice that a source branch gives you a fully unpacked and patched tree which you can start hacking on immediately, but it was tricky to get quilt interaction right, especially when doing merges. Another important lesson is to be sure that when committing a branch (say for a merge proposal), you do it at the same quilt push "level" as the original branch. -Barry signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Oct 31, 2013, at 07:45 AM, Theodore Ts'o wrote: >On a different subject, which I don't think has been raised so far --- >has the Debian maintinares for the upstart package made any comments >about bug fixes or code contributions from Debian Developers who are >personally opposed to being forced to sign copyright assignment >agreements, or for whom their employers forbid them from signing >copyright assignment aggrements (both of which apply to me). Actually, contributing to Upstart does not require copyright assignment (as for example, would contributing to an FSF-owned GNU project). Instead, it requires a Contributor License Agreement be signed: http://www.canonical.com/contributors The upstart wiki is using inaccurate terminology in the text that gets you here, and it should be corrected. The difference of course is that with the CLA, you continue "to own the copyright in the contribution, with full rights to re-use, re-distribute, and continue modifying the contributed code", but it allows Canonical to use your contribution in certain ways. Read the above link and the linked FAQ for details. Cheers, -Barry signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Oct 31, 2013, at 06:10 PM, Lars Wirzenius wrote:
>Quoting from the PDF linked from that page ("Canonical Individual
>Contributor License Agreement" for individual contributors):
>
>Based on the grant of rights in Sections 2.1 and 2.2, if We
>include Your Contribution in a Material, We may license the
>Contribution under any license, including copyleft,
>permissive, commercial, or proprietary licenses.
>
>In other words, Canonical gets the right to take a free software
>contribution and make it proprietary. The contributors gets to own the
>software, and can continue releasing it as free software, but can't
>prevent Canonical from making non-free versions of it. I don't find
>that an acceptable situation.
All developers need to make up their own[*] minds on such issues of course, so
I would never tell you that you're wrong. I could tell you my own opinion,
but I'm not sure that anyone would really care. :)
As a project leader for a GNU project owned by the FSF that does require
copyright assignments, I can tell you that FSF policy occasionally prevents me
from accepting code from people who can't or won't sign the copyright
assignments.
The argument goes: why should I have to give up my ownership rights in order
for you to accept my changes? The analogy is made to a musician who had
(has?) to give their copyrights over to the record company in order to make an
album. Those musicians lost control over their music.
(Of course, I'm not morally equating the FSF to record companies. :)
The trade-off in the two approaches is between retaining copyright while
allowing the possibility of non-free use (CLA) vs. giving up copyright but
guaranteeing free use (FSF). The FLOSS world has a very wide range of such
contributor agreements, such as the Python Software Foundation license which
lets you retain copyright and promises that your changes (and derivatives
there-of) to always be available under an open source license.
In any event, my point was to be factually accurate about exactly the deal
that you agree to in order to contribute to upstart.
Cheers,
-Barry
[*] or have their employers make up their minds for them. ;)
signature.asc
Description: PGP signature
Bug#657082: ITP: flufl.password -- password hashing and verification for Python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: flufl.password Version : 1.1.1 Upstream Author : Barry Warsaw * URL : http://launchpad.net/flufl.password * License : LGPL Programming Lang: Python Description : password hashing and verification for Python This package provides some utilities for hashing and verifying passwords, as well as generating user-friendly passwords. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPHdlYAAoJEBJutWOnSwa/Z7kP/3zv4g8r5Nwndp2ky7oRNNfQ ezf+DAQx8SPmlZ1FbabU23KIJDd42y958I4KZBuTGHVyWwkV5C+XqHwcAppDC4Ja NPW7Kzz0bwK3wL6ufQ3TuCsQdXQvajt6FEnoUK+VJAcnkw0TyVigjw3qWZPaYTTq MU7Jute3hsanD2yyf0amlehkaNdubGeZyE7WzOjS/LeioNdMnDS1aHZLnhxGBHy9 Ef5qkDqGmtLXigQPe3YyoZIXqLBGTUgaWPGiBrTUlTv3dCk8G2TB5pYbhdbwv7Df uv9B0q+LjR8hgcnUB4BeuycUq7MhlqIMpf4cvMmt6NrjrJJLuvmnMR/SGvApzC1F GObPkALjGfBs09XoBWmq7IqpG3pfrkOWju23twAkx3wQonbZWkPwfHUv7/x8tXLT ZkaZtbQp9nF36Mq3itypLvdoWxg1k/1AWI0ZkoLwA4Upnt7s42blVSLyi9zwfvV0 MYq0BUu4cRm4lZWE96gI3+TBaNkH04HV4UE347C9aDy+Ec9pC18S8C0541itADIr +UJD0G6xym4PWiiO66+o2SndHROwd8C3YaQH9XlkQjvMJUblxqdvpu2/z4afT6hK lHG+xYz2eXP4gd+plb6U08TKFOW61U1D6OJBbNgRPY/OKDu0Gk7CxY8eQvBzJHZA La2XhCtCZ0L4UjAPaUfD =W/I9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120123220411.2677.55588.report...@chemistry.wooz.org
Re: Poll (was: Popularity of bzr-builddeb and dh-make)
On Oct 12, 2012, at 09:13 PM, Hideki Yamane wrote: > bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed > Development, as Ubuntu packaging guide says) way, but now it heavily relies > on Launchpad in my point of view. And, packaging-dev can specify > vendor-specific Recommends/Suggest in its rules, then use it for Ubuntu is > meaningful. > > (Well, LP is quite nice and Debian should consider to introduce its good > point (user friendly web interface, etc), but I don't want to depend on it, > sorry). Now, clearly I am biased, but I generally use bzr-builddeb even when developing changes targeted directly for Debian, because I really like the workflow and much prefer bzr over the alternatives. When the Launchpad importer is up-to-date for a particular Debian package[*], everything works nicely and quickly, and I've even managed to make quilt work mostly non-painfully. I accept that others have different, completely valid opinions on the matter. -Barry [*] which is actually more likely with Debian branches than Ubuntu branches because Ubuntu developers will almost never push to debianlp: branches. signature.asc Description: PGP signature
Re: Poll (was: Popularity of bzr-builddeb and dh-make)
On Oct 12, 2012, at 02:22 PM, Benjamin Drung wrote: >How does bzr-builddeb depend on Launchpad? bzr is integrated into >Launchpad, but you can use bzr without Launchpad as every other DVCS. $ bzr branch debianlp:mypackage is one way to use Launchpad with bzr for Debian effectively. It's certainly not *required*, but often works out pretty nicely. Cheers, -Barry signature.asc Description: PGP signature
Re: Discarding uploaded binary packages
On Oct 16, 2012, at 03:54 PM, Tollef Fog Heen wrote: >]] Jakub Wilk > >> What makes a buildd more secure than a machine of J. Random Developer? > >It has a smaller attack surface due to few users, firewalls, few >packages installed, nobody using it for browsing the web, etc. I also think allowing source-only uploads makes for easier contributions, and thus hopefully *more* contributions. Cheers, -Barry signature.asc Description: PGP signature
Re: release goal for jessie! (Re: Source-only uploads (was: procenv_0.9-1_source.changes REJECTED)
On Nov 23, 2012, at 03:06 PM, YunQiang Su wrote: >you always need to build for one arch and test, then why not upload it? I think there are a lot of good reasons to do source-only uploads, even when you should be building locally for testing purposes. * Reproducibility - buildds provide a more controlled environment than developers' machines. This means that it's less likely that some local environmental factor creeps into your binary packages, or is silently relied upon to produce a successful build. * Testability - Is there any guarantee that a package's tests have been run during the local build process? I think it's a good thing to enable more packages tests (e.g. through dh_auto_tests or DEP 8 tests), so ensuring that DEP 8 tests for example are always run before the package is published is, IMO a good thing. Cheers, -Barry signature.asc Description: PGP signature
Re: "Do not CC me"
On Nov 25, 2012, at 11:50 PM, Arno Töll wrote: >It's annoying and it wastes my time to deal with duplicates. If yor MUA >can't handle mailing lists properly, get a better MUA. +1 on keeping >things as they are. Maybe it takes longer than 14 years for MUAs to implement standards[1]. ;) (Yes, that is a sarcastic joke! and of course I'm +1 on Arno's sentiment.) -Barry [1] http://www.faqs.org/rfcs/rfc2369.html signature.asc Description: PGP signature
Re: "Do not CC me"
On Nov 26, 2012, at 08:03 PM, Thomas Goirand wrote: >The solution to this is very simple. Have the mailing list manager to add a >Reply-To: header on each messages. > >I've done this on few of the lists I manage, and since then, nobody sends >double-messages. > >But, probably, mailman is too stupid to have such kind of options Wrong. Mailman has supported Reply-To munging for ages. >(I use (and maintain in Debian) MLMMJ, which is used by big distros like >Gentoo and SUSE). > >P.S: I know that the list manager adding a Reply-To: header breaks the RFC, >and people setting-it up explicitly on their mail client, but it works very >well... Until someone accidentally sends a private response to the entire mailing list. This is a policy issue for which the majority consensus is that MLMs should not munge Reply-To. There are contrary views, which is why Mailman supports either (we generally support the relevant RFCs but leave policy decisions to list owners). If you really want to understand both sides of the argument: http://www.unicom.com/pw/reply-to-harmful.html http://marc.merlins.org/netrants/reply-to-useful.html Cheers, -Barry signature.asc Description: PGP signature
Re: Really, about udev, not init sytsems
On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote: >Plus, you have to sign a contributor's agreement with Canonical which leaves >a bad taste in my mouth. That shouldn't be the case with true free software, >should it? In an ideal world maybe it shouldn't, but in truth it is for both open source and free software. As project leader of a GNU project, with copyrights owned by the FSF, I am required to obtain copyright assignments from contributors, which some folks feel are more onerous than contributor agreements. Open source projects like Python require contributor agreements for core developers, and this is not an uncommon requirement. We can argue about specific contribution legal documents and policies (although hopefully, not here ;) but not about whether they are a reality in today's FLOSS world. Cheers, -Barry signature.asc Description: PGP signature
Re: Contributor agreements and copyright assignment (was Re: Really, about udev, not init sytsems)
On Nov 30, 2012, at 09:14 AM, Tollef Fog Heen wrote: >There's a significant difference whether your contractual counterpart is >somebody who has the public good or profits in the pockets of its owners >in mind. In the abstract, the non-profit or for-profit status of an organization is little indication of whether they Do Good or Do Evil (or both). All I'm saying is that contributor agreements are a fact of FLOSS life, and that I've had people refuse to assign copyright to the FSF for contributions to my GNU projects. When they've stated their principles for this refusal, I can respect that even while I might try to convince them their concerns are misplaced. -Barry signature.asc Description: PGP signature
Re: Contributor agreements and copyright assignment (was Re: Really, about udev, not init sytsems)
On Dec 01, 2012, at 07:21 AM, Clint Byrum wrote: >Just any FYI, Canonical no longer requires copyright assignment in their >CLA. You are still giving Canonical an unlimited perpetual license on the >code, but you retain your own copyrights. FTR: http://www.canonical.com/contributors with embedded links to the actual CLA for individuals and entities (in PDF form), as well as a FAQ. This one seems particularly relevant to the current discussion: 7. What’s different between the new contributor agreement and the old one? One difference between the two is that the old agreement was a copyright assignment agreement (where the contributor granted ownership of the contribution to Canonical), while the new one is a copyright license agreement (where the contributor grants permission for Canonical to distribute the contribution). One new element is a promise back to the contributor to release their contribution under the license in place when they made the contribution. The new agreement also features some refinements in the language around software patents and in how the contributor disclaims warranties. What I like about this CLA is that you retain your copyrights to the contribution, so you can do whatever you want with your contribution, including dual-license it, sell it yourself under a proprietary license, etc. This deeply appeals to the artist in me. The CLA also guarantees that your contribution will continue to be available with the license it was originally granted under. Meaning, even if Canonical takes your contribution proprietary and closed, your original contribution will continue to be available under the original (presumably) FLOSS license. By comparison, the PSF contributor agreements policy is available here: http://www.python.org/psf/contrib/ with embedded links to the actual form. Again, there is no copyright assignment. The choice of initial licenses on the contribution is more limited, meaning if you have a GPL'd contribution, you will have to dual license it under the Academic Free License v2.1 or Apache License v2.0 in order to contribute it to the PSF. The PSF contributor agreement says nothing about patents or moral rights, but it does guarantee that the contribution will be available under a FLOSS license. None of the terms of either contributor agreements seem particularly onerous to me, nor should they (IMHO) be an impediment to participating in such projects. -Barry signature.asc Description: PGP signature
Re: Canonical pushes upstart into user session - systemd developer complains
On Dec 02, 2012, at 04:22 PM, Игорь Пашев wrote:
>2012/12/2 Vincent Lefevre :
>> No, that's not sufficient. You may want relations between key-value
>> pair. For instance, if you have a line with a key "foo", then a line
>> with a key "bar" must also exist. Or a line with a key "number" must
>> have a value that is a number (more generally matching some regexp).
>
>For such configs general programming languages are good.
>
>E. g. perl:
>
>$foo = "wtf";
>
>if ($foo && !$bar) {
>ohshit(...);
>}
It's appealing, but not really a good option. For example, over the years
we've had many users confused with GNU Mailman's configuration file, which for
versions < 3 was a Python file. People would put quotes in unnecessary places
(e.g. turning an int into a string), or forget one of the three closing triple
quotes for multi-line options, etc. There's really no reason to expect a
system administrator to be a Python or Perl programmer in order to configure
your system.
For Mailman 3 we switched to an ini file, and while that version is still in
beta and hasn't gotten nearly the same real-world exposure yet, I'm convinced
that it will be easier for end-users to manipulate than either Python or XML
syntax.
Cheers,
-Barry
signature.asc
Description: PGP signature
Re: dput-ng/1.1 in unstable
On Dec 04, 2012, at 02:29 PM, Paul Tagliamonte wrote: >It's currently tied to Python 2.7 (but not to a very high degree, it's >totally backportable). Mmm, Python 2. Would the authors be open to a Python 3 port? :) -Barry signature.asc Description: PGP signature
Re: Contributor agreements and copyright assignment (was Re: Really, about udev, not init sytsems)
On Dec 04, 2012, at 06:42 PM, Ian Jackson wrote: >That allows Canonical to make proprietary forks of the code (eg, to >engage in the dual licensing business model). This is very >troublesome for me; it's too asymmetric a relationship. Not to diminish your own concerns, but it doesn't bother me. To take a hypothetical case, let's say Skype were free software, and available on Debian. I write some clever hack to allow me to make phone calls in Emacs. I would have no qualms about signing a similar contributor agreement with Microsoft because I know a free version of my code will always be available, no matter what they do with it. I'd even hope they accept my contribution because while my patch has value, so does the larger body of code that it applies to, and for me, there is even more value in having that combination available upstream so more people can benefit from it. My patch has less value as a patch that someone has to apply independently and rebuild. -Barry signature.asc Description: PGP signature
Re: Contributor agreements and copyright assignment
On Dec 04, 2012, at 12:42 PM, Russ Allbery wrote: >The main issue for some of us is not so much the ethical objections to >these sorts of agreements but rather the fact that our employers flatly >are not interested in signing anything of the sort, ever, with anyone. >Much of my free software work is done as part of my day job, and my >employer is unwilling to sign any of these agreements (but is fine with me >releasing my work under free software licenses). That's a very real problem that I have encountered with potential contributors to my GNU projects. I've been on the other end of it in past jobs, where Legal is no fun at all to interact with. -Barry signature.asc Description: PGP signature
Re: dput-ng/1.1 in unstable
On Dec 05, 2012, at 01:19 AM, Mike Gabriel wrote: >Note that finally Python Paramiko has a new upstream[1]. Code gets developed >on Github[2]. You might want to file an issue about Python3 compatibility >there. Good to hear about Paramiko. There's already a Python 3 issue open: https://github.com/paramiko/paramiko/issues/16 Cheers, -Barry signature.asc Description: PGP signature
Re: Go (golang) packaging, part 2
On Jan 31, 2013, at 09:44 AM, Chow Loong Jin wrote: >Well, really, the manageable case I was talking about was pip/easy_install >inside a Python virtualenv, which is basically a Python installation that is >kept completely distinct from the system's installation and doesn't touch >anything dpkg is supposed to be managing. > >It's useful for installing crap from PyPI in a more or less standard, >distro-agnostic manner. This arrangement works pretty well for me in practice, especially since `virtualenv --system-site-packages` can usually give you the mix you need. Cheers, -Barry signature.asc Description: PGP signature
Re: Go (golang) packaging, part 2
On Feb 06, 2013, at 03:26 PM, Roland Mas wrote: >I can only speak about Python and Perl, but I don't remember *ever* having >been told to use their deployment system instead of the packaged versions of >the interpreter and modules. The closest I've seen is something like "if >you're running CentOS or RHEL, then you'll need this plethora of modules that >are not packaged, so please use our language-specific system to install them >instead". Speaking with many hats on, I think Debian Python has done a very admirable job of integrating the Python ecosystem with Debian. It's never going to be perfect, and there are certainly difficult outliers, but in most cases, things work pretty well. OTOH, Python itself has several strategies for dealing with difficult situations, with probably the most notable being virtualenv (and upstream's built-in venv in Python 3.3+). You can even mix and match, i.e. if some Debian packaged versions are fine but you need one or two missing or out-of-date packages from the Cheeseshop, you can `virtualenv --site-system-packages` that generally works pretty well. Where things get tricky is if you have multiple applications that need different versions of its dependencies. Say Debian has python-foo 1.2 which application Bar needs, but application Baz needs python-foo 2.0. Despite years of discussion, in Debian, Ubuntu, and upstream, we really don't have a good multi-version story. I think that's forgivable though because it's a Really Hard Problem and nobody's stepped up to pay a team of 5 gurus for the 25 man years of non-stop work it would probably take to solve (both technically and socially ;). This problem isn't particularly limited to Python. I'm also encouraged by the albeit slow work on upstream packaging technology (PEPs and code) to help improve the overall packaging story. I had many discussions with various packaging folks, and good developers from Fedora and other distros, about ways to make it easier to integrate PyPI packaging with distros, Linux-based or otherwise. I thought we'd made a lot of good progress, but some of the drivers moved on to other things. I'm hoping Nick Coghlan's efforts at Pycon 2013 can help motivate a revival of this work[1]. Cheers, -Barry [1] https://us.pycon.org/2013/community/openspaces/packaginganddistributionminisummit/ signature.asc Description: PGP signature
Re: Go (golang) packaging, part 2
Okay, fortunately, no bands are practicing tonight and no kids need homework help, so let's see if I can answer some of these questions. :) On Feb 07, 2013, at 08:54 AM, Paul Wise wrote: >On Thu, Feb 7, 2013 at 8:19 AM, Barry Warsaw wrote: > >> Speaking with many hats on, I think Debian Python has done a very admirable >> job of integrating the Python ecosystem with Debian. > >One of the pain points for users (I've had folks ask me this face-to-face) >with that stuff was site-packages vs dist-packages. With your various Python >hats on, can you explain why not just use "packages" instead of >"site-packages" and "dist-packages"? Fundamentally, this comes down to a conflict between Python's historical defaults and Debian's interpretation of the FHS. Let me just stipulate that I'm not casting blame, or saying that anybody is doing anything wrong. I'm not interested in that discussion, though I've had it many times. It is what it is. Old timers like me will remember the days when *nix systems reserved /usr/local for stuff you downloaded and installed from source (i.e. most everything on a usable system :). There was no /opt or FHS. This was codified in the first auto-configuration scripts. I don't remember when Python adopted the configure regime, but as long as I can remember (going back at least to 1994), a default build-from-source of Python installed into /usr/local. When site-packages was added, /usr/local/lib/pythonX.Y/site-packages was the most logical place to put it. Predating my involvement with Debian, I remember problem reports where developers of Python, and others who install from source for various reasons, would break their systems when they used the wrong Python executable to install third party packages outside of the Debian packaging system. This was because Debian allowed /usr/local/lib/pythonX.Y/site-packages to be used for third party packages installed outside the Debian packaging system, using the *system* Python, i.e. /usr/bin/python. This meant that if I installed something for /usr/bin/python into /usr/local/lib/pythonX.Y/site-packages it could easily break my /usr/local/bin/python, and possibly vice versa. I think it was at a Pycon years ago that Matthias and I discussed this problem. At the time (and probably still so), it didn't seem like either Debian or Python was going to change its policy, so we had to find a way to avoid the conflict and let both communities live in peace. Matthias's solution was the use of dist-packages for Debian's system Python, which would be ignored by a /usr/local/bin Python. Also, system Python would ignore /usr/local/lib/pythonX.Y/site-packages (but not .../dist-packages), thus avoiding all conflict. It seemed elegant at the time, and I still think this is a reasonable compromise, even though it does cause some tooling problems, which have to be patched in Debian. >The right way (IMO) would have been to put site packages in >/usr/local/lib/pythonX.Y/packages and dist ones in >/usr/lib/pythonX.Y/packages. Right now I have >/usr/local/lib/pythonX.Y/dist-packages and /usr/lib/pythonX.Y/dist-packages, >why is /usr/local dist-packages instead of site-packages? /usr/local is >clearly not the location for distro installed packages. That was my position, i.e. that system Python shouldn't have any path from /usr/local on sys.path, but that was very strongly (at the time) disputed by Debian users. To be fair, the Debian users at the time (and maybe still do) say that the right solution is for a default from-source build of Python to install into /opt/local and not /usr/local, but again, that would conflict with years of established use by upstream. That's the historical background as I remember it anyway. >Why did Debian have to invent /usr/share/pyshared and symlink farms in >/usr/lib/pythonX.Y instead of upstream having something like that in >the default install and search paths? Because upstream doesn't really care (or didn't until my PEPs 3147 and 3149 in Python 3.2) about multiple versions of packages co-existing in harmony, and because upstream Python requires .pyc files to live next to (FSVO, see below) the .py files. Debian was the first place that I recall where multiple versions of Python could be co-installed. Let's say you have both Python 2.6 and 2.7 installed, and you have a module called foo.py that is source-level compatible with both. The problem is that Python has never guaranteed that .pyc files would be compatible across Python versions. It's never said they wouldn't be, but in practice the byte code cached in .pyc files always changes, due to new features or bug fixes in the interpreter between major version numbers. So in Debian you have a situation where you want to share foo.py across all supported and installed Pythons, but
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On May 03, 2013, at 04:38 PM, Josselin Mouette wrote: >- source-only uploads >They are pushed to the buildds, and the produced binaries >(including arch:all) are put in a staging area (much like >incoming.d.o). These binaries can be downloaded, but >the .changes cannot (to forbid skipping the second step). For the 13.04 release, Ubuntu made a change to its procedure whereby source-only uploads to the development release (e.g. raring) actually go to e.g. raring-proposed first. The builds are attempted and only if they succeed, pass their autopkgtests, *and* don't make the archive less installable than before the new upload, are the packages copied over to the release, e.g. raring. In practice, I think this works very well. No users are exposed to broken packages, or new versions that introduce more installation problems, and developers can upload source-only. Mostly gone are the days since `apt-get dist-upgrade` is a cross-your-fingers-toes-and-eyes crap shoot, and the in-dev release is pretty darn usable even before the first alpha[1]. Devs should *still* build and test locally of course, but this provides a great backstop, and it does make for a very quick and easy development cycle. -Barry [1] Even the first day after the stable release . signature.asc Description: PGP signature
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On May 05, 2013, at 01:12 AM, Roger Leigh wrote: >There's definitely an open bug for adding this, and I'll be happy >for it to be added. It shouldn't be too hard to implement, though >we would probably want to make it configurable whether the repeat >build failing should fail the build as a whole. We probably want >to do the repeat after we've copied the built files out of the >chroot. We could probably also compare the file paths between >the source and binary packages in the first and second builds; >comparing the content itself is probably not realistic. I'd love to have a --twice option in sbuild. Should it be the default? Perhaps, though I would probably --once for most of my build debugging, at least until a single pass build works reliably. Then I'd run it once more with --twice before I blessed the local build. -Barry signature.asc Description: PGP signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Nov 16, 2013, at 12:01 PM, John Paul Adrian Glaubitz wrote: >Your first mail came with the argument that you think that >xemacs is more visually appealing than emacs. Honestly, emacs >is primarily a tool and not an optical gimmick. Visual >appearance does not bother most users, I'd guess. Most emacs >users use the terminal (-nw) mode anyway. I'm not going to argue for re-inclusion of XEmacs (but I won't argue against it either - it would be helpful for me testing some Emacs Lisp packages I care about). Despite being an old Lemacs and XEmacs user for years, I gave up on XEmacs back in 2008 in favor of GNU Emacs. I will dispute the terminal mode usage though. Most Emacs users I know of do use the graphical version. >And the beef I have with xemacs is that it's development >has factually ceased. Looking at the changes over the past >months, I see only marginal changes [1] but no real development. I agree that XEmacs's time has come and gone. -Barry signature.asc Description: PGP signature
Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor
On Nov 16, 2013, at 03:32 PM, Mark Brown wrote: >There are other users who do use graphical mode, indeed I was reminded >at the mini-Debconf today that the main reason XEmacs got forked was >that GNU Emacs was too resistant to implementing a GUI. I guess some >people use menus or whatever but I expect you'll find it's mostly just >to make it look pretty and smoother interaction with other programs. Well, this is getting off topic, but the real history is more subtle, complicated, and contentious than that. At least as I remember it. I was an early user of Lucid's Energize product and thus Lucid Emacs, the precursor of XEmacs. The wikipedia page on XEmacs has a decent, short, and neutral summary of the history. Lucid Emacs was groundbreaking for lots of reasons, most visibly its embrace of X and all the things a real windowing system brings with it. Syntax highlighting (font-locking) was another innovation, though when GNU Emacs adopted similar features they were implemented differently (and at the time, I felt, not as well, since I did the original patches to support the dual comment styles of C++ in both editors). I haven't looked at the guts of either editor in years. -Barry signature.asc Description: PGP signature
Bug#732038: ITP: singledispatch -- single-dispatch generic functions for Python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: singledispatch Version : 3.4.0.2 Upstream Author : Łukasz Langa * URL : https://pypi.python.org/pypi/singledispatch * License : Expat Programming Lang: Python Description : single-dispatch generic functions for Python PEP 443 proposed to expose a mechanism in the functools standard library module in Python 3.4 that provides a simple form of generic programming known as single-dispatch generic functions. This library is a backport of this functionality to Python 2.6 - 3.3. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSqkKcAAoJEBJutWOnSwa/3Y8P/27eSCZRYc6GR5sLMkbZLcVg 6/5wlAAbENNfKlB+tpa7BI5RVXne58ijSMyggulAr+0EjoRAx0LB0leKKddXcnth d4JUUkYzFkabdx+SUWLIDOV0vsefzrwDwdDQig5sSn4XL1AjYjiLcH7BGjdSX1za r4XR8PGuX4qz/GcyDSqh1Dc9kUvMbdo9MvrNNmZlTOhFE8L7jFR4pVO8rc8k/06x ZdscmLuLXHFE7iI1T269LydEq8zu9w3I0yNJSE3UEY971UUva7aAkOvEYhQBgmHE uHcBEsmDuux4biO1yaap/SdwbyuoWJp/SJ85GN+N0bim7Nz88SPjEnyiAFFQz+qe omQaosYPNid5onFIh/Krx3Q/hvQbF/y7S+oIo8hhozmsQbpnkGW9Lj7kWGLvdTqD WWGX+oHx7gcqf6qdGmZHRs8nsAiTGdWuIM26jAa8MArvlWIsV2SmYzsKC+8TeDJN 84wS7+nGlr3uc2H0ZkX60Hz5b0sKKwVrXU7VT9ct+YQ8AUoLwP2sfhdC3x9IGiM8 cfzLgfQBb5tQlzglOpmQ+tkMCimVYSHFbuEuoDYIKI5yg40rrdmS62Hu7VkCdKSt IvG8+5+bF3ykywDHIFolouMsECUb7szi2i6xjJNxmWceL0ohCXxvFq+TkohEphTI vXRsWuA8g62xRuOKQTSl =ejfI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131212231126.2977.39242.report...@chemistry.wooz.org
Re: Ubuntu will switch to systemd
On Feb 14, 2014, at 07:40 PM, Daniel Pocock wrote: >Quite the opposite - some people felt it would be inevitable that >Debian choosing systemd would effectively be a death sentence for Upstart Keep in mind that (just as before the ctte decision and Mark's announcement) Upstart is free software, licensed under the terms of the GPLv2. This means that Ubuntu's decision to follow Debian does not necessarily mean a death sentence for Upstart. Sure, it probably means that Ubuntu will at some point cease to put resources into the project, but just like any other GPLv2'd software, someone else may come along with a new vision, crazy idea, or an interesting repurposing, and adopt the code. And just like before these decisions, if that person doesn't like the CLA, there's nothing stopping them from forking the project and maintaining it themselves under a different regime, or no CLA at all. This may seem like a silly or moot point, but it actually shows the beautiful thing about FLOSS. Projects only die because no one cares about them any more. Cheers, -Barry signature.asc Description: PGP signature
Bug#740195: ITP: nose2-cov -- A coverage plugin for the nose2 Python testing framework.
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: nose2-cov Version : 1.0a4 Upstream Author : Meme Dough * URL : https://pypi.python.org/pypi/nose2-cov/ * License : MIT/X Programming Lang: Python Description : A coverage plugin for the nose2 Python testing framework. nose2 plugin for coverage reporting, including subprocesses and multiprocessing This plugin produces coverage reports. It also supports coverage of subprocesses. All features offered by the coverage package should be available, either through nose2-cov or through coverage's config file. I intend to package this as a Debian Python Modules Team package. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTDjiGAAoJEBJutWOnSwa/kVMP/2HGLBlTd2HpiioVNRHMkfG0 QKhguKxvG/4IYovL/5kYyINLkHZouAsfYzDtIh/kXyYv07XB5fGaRunrbBjkbCxf XiFukpwbAqGA+JjPTzQsC9Xl6Ae4OrTZkW01cCh2Qrob8MZwXt1zepgaGt/KW9qI 1oHqfeKyVeoMinN6uNdw3y1EXzoAA7jXzapySCbrk9AsNChXSmoTSvurhZOd0YQE OdA854IMC6VUQvl7MVaRwo8AabBTQezoJ/GX9XS1B8z3hx7YmW3fe6ixemZsg3Fk 6DLMsTmj+bxXjOAwFyhZg7J6qb5mpk4aSplvhiF+D4M4Wlrb1o35Q/whWnmLlFDq 4ff0Amoaa2WfZtk16mrb5hC1uy/PTO1PgI15yV/2lHj6TvuD4rK1ZiTxP66pXI5i 8SzQhlbfWqXsWdZxuocQTGHaWOrYfbOjkx0hVThDcGYx6TaXcKCZFtybckywS2sj mm1tFTrF/lcTI+6zqcjLJoSbw0+l8X6Cqb647zqCvya7Td74VXvfW/0GzZ1eS4XK wcQZzDtaxTgDn66DpCd7zwQLrwSQpKdG2jwiOGaLHflV2NdAyawp5VxUjmu0ux6g RYOJx6mcagAS9+8bZvOHenKjvEJNZ/mt/1blsCyba3cku3NqMA/7mP3ZDQo9ytUi 49r93SBYaVWIjSw4oFvs =P9SJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226185504.18945.71862.report...@chemistry.wooz.org
Bug#745673: ITP: wheel -- PEP 427-based built-package format for Python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: wheel Version : 0.23.0 Upstream Author : Daniel Holth * URL : http://wheel.readthedocs.org/en/latest/ * License : Expat/MIT Programming Lang: Python Description : PEP 427-based built-package format for Python A wheel is a ZIP-format archive with a specially formatted filename and the .whl extension. It is designed to contain all the files for a PEP 376 compatible install in a way that is very close to the on-disk format. Many packages will be properly installed with only the “Unpack” step (simply extracting the file onto sys.path), and the unpacked archive preserves enough information to “Spread” (copy data and scripts to their final locations) at any later time. The wheel project provides a bdist_wheel command for setuptools. This package will be team maintained by the Debian Python Modules Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTWESlAAoJEBJutWOnSwa/XWUQAKBv87yqSQ7n8PfenfNNQlbp BAtbP+nmFTost7t1Ooc2/k5EEkEH70yWqqEWw6bTWHCHRJiC62rT4iy1h1+LKX8T natPvzYlSwodiO0szFj3+RgRZWgIBjoRF1ZOto5CfcaajXC46sQGrvoVVaoHWC0j YCB74U3KV60zL3wxuCatBI/gYMS5GnFpr6lZmdS/HlYgS2Rk8nSh9SZIKBK8uInJ v+OwA3XEGfwYckq6VpFC5Tm+GLPsEaCaYm3JzW4T9lx3L0Hv1i6BsyUDp53hDv54 /g1COu4B9f+A6AAPfwtzm3fwj8znUwj9/xluYZPhDE13fAjbKsVGs2tyf3drs/aL z7bYAGD0azvnBDXkmBOwY2z5BNf643dTqtUIg58en8FicEJ/Gb9vfeowN/Yvmd+w 8pTCDIoeFQRQIN4I1pXyPuJs2sbpVGaO+xCUh6vuTlt10IXsQo5S0+PKeB7MJKxk 6HWkTjO20InXXbxWeJY7hK3MtOrCBf1XzxJfq1JBrptUO7mjksQxfygXDHbLlRKD pVGn0/hlGcQZzOttQ2K4pkKyRJgAevkMDfStpUzqsbt93GGT9014m3WmUm9OE98i KgWMpWGjDCsNfBISYknA+SAsaTUbmaH6gesVHXuGS2aOX/uFNj2nB/SwC8NDBICG h00Kyii3ngcwZm4rHBTO =KFyP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140423225432.2517.5700.report...@chemistry.wooz.org
Re: what to do with wayland, python3, gdm3/systemd, ...
On Apr 28, 2014, at 07:16 PM, Osamu Aoki wrote: > python3 support or not (Are we moving too?) I will of course echo Matthias and Thomas on the issue of Python 3 support. I'd like to see us migrating to Python 3 for any "system" scripts, i.e. scripts that come with Debian by default or are relied upon by a base Debian install. Let's move these to /usr/bin/python3 shebangs! I haven't done an inventory of those recently though. There are tons of resources available online for porting to Python 3. This is a good place to start: https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef -Barry signature.asc Description: PGP signature
Re: what to do with wayland, python3, gdm3/systemd, ...
On Apr 28, 2014, at 01:12 PM, Felipe Sateler wrote: >Both soappy and fpconst seem dead upstream, which makes option 2 more >attractive, but it looks like the soap implementations in python3 do >not get along very well with debbugs, as Jordan notes. A REST API would be fantastic. The best REST library I've used is restish, but unfortunately it doesn't have upstream Python 3 support yet. Other libraries exist for doing REST but IMHO they're not as nice. -Barry signature.asc Description: PGP signature
Re: Alioth tracker
On May 12, 2014, at 07:57 AM, Charles Plessy wrote: >For mailing lists, I read in the thread that it may not be a problem anyway, >but I just wanted to add one thing: in many cases the lists to be created are >a maintainer list and a commit list, and this could be replaced completely by >the “new PTS” (see http://dep.debian.net/deps/dep2/ and >http://pts.debian.net/). People who have time to give but do not have the >right skill set to work on Alioth or Mailman may consider helping the new PTS >instead. I don't have time to work on Alioth, but JFTR, we (the GNU Mailman development team) recently announced the first full-suite beta release for Mailman 3. It's possible that even with the usual beta-quality issues, that MM3 would make a decent mailing list framework for this Debian use case. It has some interesting features that might make integration easier, and I would be highly motivated to help others adapt and extend MM3 for Debian's use. Contact me personally off-list or via IRC, or start the discussion on the mailman-develop...@python.org list. Cheers, -Barry signature.asc Description: PGP signature
Re: mailman3 in Debian [was Re: Alioth tracker]
On May 12, 2014, at 05:46 PM, Thijs Kinkhorst wrote: >Mailman 3 is completely different from Mailman 3 and I see no synergy in >basing anything on the existing package. As of now, to my knowledge no >migration or upgrade scenarios exist from MM 2 to MM 3, and I'm not sure >if such code will be there in time for jessie. We do have code in the core to do updates from 2.1 to 3. It's well unit tested, but not battle tested. >It would therefore make most sense to me if MM 3 packaging was started fresh >with a new mailman3 package, allowing for both MM3 and the legacy release to >coexist while MM3 matures. When reliable upgrade or migration scenarios >exist, the mailman3 package could take over the mailman package, but I expect >that to be the case only after jessie. > >People interested in MM 3 are therefore very much invited to just start >packaging it under the mailman3 name, in any way they judge best. Agreed. The MM3 core is a well-behaved setuptools-based project so its packaging should be relatively easy. Hyperkitty and Postorius are Django-based applications. We (upstream) very definitely expect that people will want to run existing MM2.1 installations in parallel with MM3, at least for a while or while they're testing out the transition. I may not have time in the immediate future to do the packaging myself, but I will assist others in any way I can. -Barry signature.asc Description: PGP signature
Bug#748404: ITP: cov-core -- plugin core for use by pytest-cov, nose-cov and nose2-cov
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: cov-core Version : 1.12 Upstream Author : Marc Schlaich * URL : https://github.com/schlamar/cov-core * License : Expat/MIT Programming Lang: Python Description : plugin core for use by pytest-cov, nose-cov and nose2-cov This is a lib package for use by pytest-cov, nose-cov and nose2-cov. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTdpAPAAoJEBJutWOnSwa/j+cP/1jX+jb8iAdS9LDX+JGdk8xM 7BXsRlWWFoHBhJwr9o/qO2Vagz+5IQwk1wDmQqHiZFnJKa8j8BGI/DgTmCZo3QtG JwRbHzqxxxOd0pwSql+MXFKoumedBeA7o5xKYOHq4pajbqcSaX9w3F6FGGdjdM+y LsOl0sjsD3VYRKPRUVpsxmi9mcFiBQv+J749OClc+tQZhLk7FRkbFIVWLgoFloHp R8ganvuXfv6DKzWG6EYtWKh1yYzgElaapH0yG+mfh6ZDPZgqGV+BCtNDujaRPrQ9 ZsggRkwQOXR8yGtVc/oAOLXLCgkq5YsrDIM3DAqOzIkTkSipQQcg7aMSrpzO0pmX 042Gbx7bu+lx3k+yULk3fCQTH618Y/h3XQjJixEehqkseTE/ALyE/5aunDI2F5Ko aHm//yVtz+1pziMsFYV5F1QeojBgDHOsJgaI/AKnEImq9jGximPUXhNaQ2wEV1P9 dg2vvF3WME1D9x1yRZriF4iVAusZOzwwU6Sqk/SsMfzwf4cTaOBsQTWnIaLy3Z31 gGFGCfQKyWG/XdzrwCuEQlYixTFEmhtn5S/unEyfAQHQr3l4YNKjFLOYjqnaQIug wPz7QZFK3OENGmyQ3D/4NzY7uP4nE4nhsuSbEkXNdnlQ6eNoAeiiI1wRGM5wJzbk 8HeksIeanm8Gjq49cRL8 =Rwgd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140516222418.1377.20817.report...@chemistry.wooz.org
Re: "Python2.6 as default"
On Apr 09, 2011, at 01:38 PM, Scott Kitterman wrote: >We've treated python and python3 as separate runtime environments. We also >have a default python3 (just in the middle of transitioning to 3.2). The >only meaningful change that would make python3 the 'default python' is if we >pointed /usr/bin/python at it. It is definitely premature to do that. If we >ever contemplate such a change is will be several releases from now. Just as a point of reference, there is a new PEP concerning recommendations from upstream Python: http://www.python.org/dev/peps/pep-0394/ Cheers, -Barry signature.asc Description: PGP signature
Re: "Python2.6 as default"
On Apr 11, 2011, at 07:22 PM, Scott Kitterman wrote: >Hopefully it will gain additional sanity before approval (the authors did >improve it based on comments I sent them it could still be better). The >notion that /usr/bin/python pointing to any python3 version in the near term >is anything other than crazy talk is, well, crazy. I agree we're[*] not there yet. But I do think we're at a tipping point. At Pycon 2011, where in previous years the responses were largely "we have no plans to port to Python 3", it's now quite common to hear "we have an experimental branch to support it" or "people are working on it". So I do think it's worth Debian thinking about, planning for, and possibly helping with a transition to Python 3. Python 2 won't go away any time soon. If I had to guess, I'd say we're probably 18-24 months away from actually being *able* to make python3 the default, which I think is pretty well aligned with Guido's 5-year plan. Cheers, -Barry [*] and by "we" I mean the larger Python community, not just Debian. signature.asc Description: PGP signature
Re: "Python2.6 as default"
On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote: >I think it makes more sense to have a release or two where users can >fall back on python2. Well there needs to be at least one >where /usr/bin/python becomes python3 alerting users to the change and >giving them the python2 fallback, just so they have time to be prepared >for the permanent change. I do agree that we could add the python2 symlink now so that folks who want to prepare can start changing their #! lines to use /usr/bin/python2. Cheers, -Barry signature.asc Description: PGP signature
Re: Uploading to multiple distros
On Jun 02, 2011, at 10:28 AM, Peter Samuelson wrote: >Since syncs from Debian are actually supposed to be the majority of >packages in Ubuntu anyway, why not just do that - a real sync, not a >fake simultaneous one. I don't live in the Ubuntu dev universe, but >given how common of an operation this apparently is, I'd think the >tool(s) to do it would be mature and easy to use. Sure, you have to >wait a few minutes until you get your ACCEPTED mail from dak, but what >of it? The mail is your reminder to finish the job. How can we help Ubuntu developers do the right thing? Are there tools, processes, or documentation that we can develop that would make it easy(er) for someone who works on an Ubuntu machine, is well versed in Ubuntu culture (processes, tools, etc), to integrate with Debian? -Barry signature.asc Description: PGP signature
Bug#638859: ITP: python-flufl.lock -- An NFS-safe file-based lock with timeouts
Package: wnpp Severity: wishlist Owner: Barry Warsaw * Package name: python-flufl.lock Version : 2.1.1 Upstream Author : Barry Warsaw * URL : https://launchpad.net/flufl.lock * License : LGPLv3 Programming Lang: Python Description : An NFS-safe file-based lock with timeouts -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110822143950.10368.57568.report...@chemistry.wooz.org
Bug#638861: ITP: python-flufl.bounce -- Email bounce detectors
Package: wnpp Severity: wishlist Owner: Barry Warsaw * Package name: python-flufl.bounce Version : 1.0 Upstream Author : Barry Warsaw * URL : https://launchpad.net/flufl.bounce * License : LGPLv3 Programming Lang: Python Description : Email bounce detectors flufl.bounce is a library providing a set of heuristics and an API for detecting the original bouncing email addresses from a bounce message. Many formats found in the wild are supported, as are VERP and RFC 3464 (DSN). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110822144430.10413.36301.report...@chemistry.wooz.org
Re: forwarding bugs upstream - opt-in, delayed, automated
On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote: >The main thing that is blocking me from implementing it currently is a >set of perl modules which can handle the hard bit of managing a >mailing list correctly so I don't have to write them from scratch. Can you provide a bit more detail on this? I don't know what you need but maybe it's something that Mailman 3 could help with? -Barry signature.asc Description: PGP signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Sep 15, 2011, at 06:47 PM, Don Armstrong wrote: >On Wed, 14 Sep 2011, Barry Warsaw wrote: >> Can you provide a bit more detail on this? > >I am looking for a set of perl modules which can handle being fed mail >and managing a subscription list in response to that mail while also >allowing for subscriptions/unsubscriptions from an external interface. >Such a thing may not exist at all, but if it does, I would rather like >to avoid reinventing the wheel if at all possible. Thanks. >> I don't know what you need but maybe it's something that Mailman 3 >> could help with? > >Mailman3 isn't finished and is a complete system for dealing with >standard mailing lists which don't get created or deleted on the fly. I can't/won't help with the Perl bits, and don't want to clutter up this mailing list with discussions of MM3, but if you're interested in exploring possibilities or influencing its feature set, please contact me off-list. Cheers, -Barry signature.asc Description: PGP signature
Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths
On Dec 12, 2014, at 08:36 AM, Ben Finney wrote: >Even for the source package name, “pathlib” is IMO too general. This is >specifically a library for Python programmers only; its source package >name should not grab a generic name like “pathlib”. Why not first-come-first-served? Cheers, -Barry pgpgKr8SfmhUi.pgp Description: OpenPGP digital signature
Bug#778708: ITP: python-pex -- library for generating Python executable zip files
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-pex Version : 0.8.6 Upstream Author : Brian Wickman * URL : https://pypi.python.org/pypi/pex * License : Apache-2.0 Programming Lang: Python Description : library for generating Python executable zip files pex is a library for generating .pex (Python EXecutable) files which are executable Python environments in the spirit of virtualenvs. pex is an expansion upon the ideas outlined in PEP 441 and makes the deployment of Python applications as simple as cp. pex files may even include multiple platform-specific Python distributions, meaning that a single pex file can be portable across Linux and OS X. pex files can be built using the pex tool. Build systems such as Pants and Buck also support building .pex files directly. This package will be team maintained in the Debian Python Module Team's git repository using git-dpm. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU5PR1AAoJEBJutWOnSwa/Jx0P/jter0F7J0F8E29zUdRXwUo3 xKjUIrdBiCuiAg++R6A9S6EKdSTJQa3cQwu8mOJYyJ7/VoxDaSZZC+xxc/luhv0h JyJ7+8kpx7z1qJ5ezxIEs+6Fq6ZrxLEvq8pXZkHJa+vcSiexiuytPtZGvE9Qaq0c 6YC//qt46QibewWsx/2QvP7G4xvO6tT9+kJ82eFxgOGfQ0Lxpf/zutp/7pfXpqxb EDYWogvHo5EMplK4PZ9U5mf7MHl4TNtLRkH6qvGCf5I14IwBOhdcvpgkEHAu9jU4 bSXIP4dGOKfGUpSud/rtTat1Dp/WvWdRDRS8XXOWO213lYMwFrriCK1vOUxbmrEm lNBfIYpjMiYyr1u7sqFjNl5AbfJOOaW5cWJJhQobUDC7fd22gBqCl1h/tIO43J9z BfpjGxcdQaElP3aUJO3iv7rs3wm9s0EFSLqHiyP0u8y0DbgwmUT6et3J4Ltcx7jA D+HAs9tgTjW0ejLLedicaX8ViSSs1aoHlgxz8SundksqqvaGMFI850VyZZ+okuGZ UI8C/7MPZ8FnLl1lOuTwsi58G3wDwE0kdLAysCYeJUFBNZX1Ig10fb/8BzpZHwvI qQykcwU7Jx7wBjLavvEEgGenHPi2vi4l2dElJnedl2AhgqNydB9YveY/77Mc8wmm ohvakUnFujEN7gzdsgmC =nmmh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150218202215.1477.3996.report...@chemistry.wooz.org
Bug#782250: ITP: python-future -- use a single, clean Python 3.x-compatible codebase to support both Python 2 and Python 3 with minimal overhead
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-future Version : 0.14.3 Upstream Author : Ed Schofield * URL : https://python-future.org/ * License : MIT/X Programming Lang: Python Description : use a single, clean Python 3.x-compatible codebase to support both Python 2 and Python 3 with minimal overhead Easy, clean, reliable Python 2/3 compatibility, this is the missing compatibility layer between Python 2 and Python 3. This package will be maintained within the DPMT. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVJoR7AAoJEBJutWOnSwa/R0cP/2omE2qkALBc0LMlWpc3P3ih Y1Zs4q/0ZyZ+/aa3sA9rfW18V9JY7APMh3FOXtxJNJKcGp3FygsTWtZOUNjtUAGf 45QU7e7NlJ8Y2iaqSeHiKjce+aoO2nB5KO/CYvtXNxMSUP/mGk2Bx81mLIziMEU+ V0QODuTQC64zSMplwvl+aT9VTrEAH/ChyzN43neWwZcfV9NbWQlDuaBqGtvNiJv4 FQKwIKfNI8G81QBqX8gTDnEsvYIu+5M+uoTqAaBGgC3NzkFcXeFPQrEZ4ub2Qu75 kUcpExKpaFN1dpvAY1J8SOgpxPVOKy4N/Tjo9UTH3wJG6Glutko7Jauy9+4H0cii hE3/qHSpxPncrRdvB2Pk34bGaOIOFpJtQYCQu7/oXxjiw6gjPBalYJQxrQIB6Gkz IULbKlfFRptpB4ZHlGLWMIks7SJcOiKZSBwf6s3pN2Mlee0WQBY4K409PfGF2xJC kR16QboIX8QoQs64anltTUuLf42dRZJrDj898CqPv8AzS8PI232QhTZzwDWfdzc+ uto/JFu56/ZZOfhGNlhiLYxjXeisUNgPAFGoXPZP9GqkQse8RxV3tw4sb6+iW+5a 9Jq6DJnfXKezl3wjy9AcVTRgLxy9thJRdaLXfVy9Kz4rig8fHeSmktTnki1HICd3 D1ii0n1UKmAhrQbzaxbt =njpk -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150409135404.2128.16844.report...@scars.wooz.org
Re: debian github organization ?
On Apr 16, 2015, at 09:04 AM, Dimitri John Ledkov wrote: >I'd rather see gitlab.debian.net :) +1 I've started moving my personal projects to gitlab and like it a lot. Cheers, -Barry pgpEtXwHRd4zO.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 18, 2015, at 02:56 PM, Stuart Prescott wrote: >arch 7 >bzr199 >cvs11 >darcs 832 >git12439 >hg 65 >mtn23 >svn3593 I hope at some point soon after Jessie is released that the DPMT will officially switch from svn to git. Cheers, -Barry pgpZjFyDVmRKn.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 16, 2015, at 07:19 PM, Andrew Shadura wrote: >> I'd rather see gitlab.debian.net :) > >Why Gitlab when there's Kallithea? :) Kallithea is under consideration as forge for upstream Python: http://legacy.python.org/dev/peps/pep-0462/ Cheers, -Barry pgpxAfgqu1BlU.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 16, 2015, at 11:13 PM, Russ Allbery wrote: >Launchpad, similarly, is probably suffering a lot from the decision to >only support bzr. That will probably be solved soon. From watching the commits to Launchpad trunk, it looks like git support is progressing nicely. I expect after some reasonable amount of testing it will land in production. I'm quite looking forward to it, as I think the Launchpad bug tracker is really nice. I love being able to create multiple bug tasks for a single bug targeting multiple versions and projects. Cheers, -Barry pgpKZK1RmqAfa.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 22, 2015, at 10:40 AM, Paul Wise wrote: >I don't like it due to the JavaScript requirement, many things just >give 500 Internal Server Error unless you have JS turned on. Can you navigate github without JS? Cheers, -Barry pgp2Hk9JVhtjQ.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 22, 2015, at 11:01 AM, Paul Wise wrote: >Seems to work fairly well, certainly it is robust enough to not have >500 Internal Server Errors. File a bug? :) Cheers, -Barry pgp393q5a3UIo.pgp Description: OpenPGP digital signature
Bug#785059: ITP: python-cachecontrol -- a port of the caching algorithms in httplib2 for use with requests session object
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-cachecontrol Version : 0.11.2 Upstream Author : Eric Larson * URL : https://pypi.python.org/pypi/CacheControl * License : MIT/Expat Programming Lang: Python Description : a port of the caching algorithms in httplib2 for use with requests session object This package is a new dependency for the latest version of pip. To upgrade pip, I need to get CacheControl into Debian. I plan to maintain it as part of the DPMT. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVUSpsAAoJEBJutWOnSwa/VJAP/3A4D8w4wgL4haA25F3XNmPE B4pnRshBmpxjCbyx4EXOGrJWnBp/GIo22UkbS7zgxigQ4HgIHKbYnHW6KnmJpVPe wSFWwkbS0QKISZ3rtsRUCwvJZZY156/TOkY3lvACtToPJ9sDho319i6KKIaCCL5C +Owr4/u7eg24fpuG+HekDmYHdU7uTmGd2ghqg6btntz23eHrGJQh8kJhlKjcnGbk tX3p4VGzvIJ9ERPbz4s7OLUBVjJSnUaiZvhwerdNztYBBMXTYe661PJlOvpYrLMw 9l2QIsQ+kmPBcDKyTQ+r9Gz6Vt85fK6KgEmgT653g3C7c1bT9t0PF+y7VqE1jLJb CMLpL5LTY3Hfrb0GqDKrPiR3Wrq1hg9uHBts67AkBAcwYO+NDOLu1r9TU4dzGIUa zZXIxy/aCViOi6U0P39Rz5lZeqwCd5y0RybqgapIpeyHZZtrpGAJ8NLUBkjkITKl e7u+WwKsawLLqc0UujEYSGKrrlPVAGvkJQNxGGaZObwUC7AR3nletrAhfd97peeW VP7MvcCikMI3tAvxrQmosNeK/pVnCtzk/Pcz44EW0sGVdFVec8Y74djTSminXltX romHqVfQGnRDBm6XOxhA/4d3q68h2XVAhKvcCVM53B5UYSouSNAxT7psh9gtOXz/ 6KDAdcweO9D1EJ2mA+Hn =IT5K -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150511221718.13766.62170.report...@chemistry.wooz.org
Bug#785242: ITP: python-pluggy -- plugin and hook calling mechanism for python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-pluggy Version : 0.3.0 Upstream Author : Holger Krekel * URL : https://pypi.python.org/pypi/pluggy * License : MIT Programming Lang: Python Description : plugin and hook calling mechanism for python pluggy is a new dependency of tox 2.0. It provides a plugin manager as used by pytest but stripped of pytest specific details. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVU52aAAoJEBJutWOnSwa/fZAP/Au8xOcqdXt3HiIDJ8oUDRID fCQwiu4XV3jRRgeuOzCWOW5Vt2tOEM1my5TM+NrjZiJcEquL8GJdZvlNZdQ6Sh+f +huI+0X13IhMqfXWh6f9eJBSmFCO9fHRBov4fqk9G+0BnFRQlv0Zoa5IWx5+CjZT qng+Zk00yiOz1zy1/YUubAhc4MODuPsxJiYjMGDUf3HhoFoG6l9I9KxrN+DLT45M do7RV5E5HWc4pcWCv2CiHoFQm5sM6KyGf2fzUwtJwqGSp5Iji6nFa64qRmBU7U6U M1JfDl2ij4iczcpUhVva1u/RYDquUPoKrJVmZFE2+Ae/ySYVp7754jBjHxnIOjOv KBsZA82cx1Jhb+cKZ5oSkNLcyv8lRGyhP9Z+QWY11FASWhy4uoXud+IvioqSd9ez ZaCvSRqC6tfGP6hJex8Zqi6YTZ/Wn3l4vsYwCsv/4xYF5BcsEPpxvVNVnmWCH+bG Fp7OsEtVWU1ZjHFgZY+ujls1zGEtjjHgk+MrkTAAHbe6uAuNqYSSsrcc+nMFyhqJ CPMK9EB4rAaltbV0Qb/StlCL4Byl7LeBqxOfxS/ykoTHHi6hIcuXia3CWEcCFHz7 EIHpgdrGGEbKk8Z+m/X3BecxqHc7pT0hdJFjUgRw12uS/YJ6QQEbtQ29LDWpW1aQ j10UCXpmvoTDdng+FsQZ =fQQ8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150513185316.10515.65525.report...@chemistry.wooz.org
Re: MBF for python-support removal
On May 20, 2015, at 04:36 PM, Luca Falavigna wrote: >Does anybody else have comments / adjustments on the text above? >I'd like to send out the bugs within the end of this week. LGTM. -Barry pgpUHroOdhwCe.pgp Description: OpenPGP digital signature
Re: Ad-hoc survey of existing Debian git integration tools
On Jul 21, 2015, at 06:46 PM, Ian Jackson wrote: >That is, the dgit git tree contains the patches in debian/patches/ but >also contains the implied changes in the main source code. If you add >commits yourself to the dgit git tip, new patches will generated from >your commits. I think then that dgit's requirements are not compatible with git-dpm currently. IIUC, git-dpm presents you with either a patches-unapplied-but-with-debian/ view, or a patches-applied-no-debian/ view. E.g. `debcheckout python-pip` You'll be in the master branch which is the packaging branch, but `quilt applied` returns nothing, and `quilt unapplied` shows you that the patches are not yet applied. `git-dpm checkout-patched` leaves you in the transient `patched` branch, where the patches are applied, but you do *not* have a debian/ directory. `git-dpm update-patches` converts the commits back to debian/patches, but again leaves you patches unapplied. There's no current view where you have both patches applied *and* a debian/ directory. (FWIW, bzr-builddeb actually does present you with exactly this view, patches-applied-with-debian/) Cheers, -Barry pgpdUR4cVw82y.pgp Description: OpenPGP digital signature
Re: Ad-hoc survey of existing Debian git integration tools
On Aug 04, 2015, at 07:47 AM, Ian Campbell wrote: >But git log shows that they are, it's just that Quilt is unaware of >this (no .pc directory in git). Perhaps grub and python-pip differ here >but I don't think so. I think you're right. I took a look at a different package (pip *is* a little weird atm) and it does seem like in the master branch you have patches-applied with a debian/. `quilt push` confirms that the patch can be reverse applied. I think you're right that there's just no .pc directory so quilt is confused. >BTW, IIRC Colin had somewhere (on his blog?) a script which could >reconstruct a .pc, although I think with git-dpm you never actually >need to use quilt, since you should instead be git-dpm checkout-patched >+ git rebase. Yep. Cheers, -Barry pgpxPGBvp68rn.pgp Description: OpenPGP digital signature
Bug#842738: ITP: python-webencodings -- Python implementation of the WHATWG Encoding standard
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-webencodings Version : 0.5 Upstream Author : Simon Sapin * URL : https://github.com/gsnedders/python-webencodings * License : BSD Programming Lang: Python Description : Python implementation of the WHATWG Encoding standard In order to be compatible with legacy web content when interpreting something like Content-Type: text/html; charset=latin1, tools need to use a particular set of aliases for encoding labels as well as some overriding rules. For example, US-ASCII and iso-8859-1 on the web are actually aliases for windows-1252, and an UTF-8 or UTF-16 BOM takes precedence over any other encoding declaration. The Encoding standard defines all such details so that implementations do not have to reverse-engineer each other. This module has encoding labels and BOM detection, but the actual implementation for encoders and decoders is Python’s. This package is a new dependency for html5lib, which in turn is a dependency for python-pip, so it will need to be rewheeled. I intend to package this as part of the DPMT. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJYF6icAAoJEBJutWOnSwa/HggP/2V7UXMmQJg7l7cMeDH4rnOV 8cAGsYB2bAw+U8ShyI4Q27S+NfNm9Xa57voi0lv1pA1/SUn3Ragl6+NWr0XYrhBN 2oSm2myN5GWUZSCyAWAxletAIwPsYJXuuaiDBs1aMgALpd28YxROO1OY/KRyQNCJ HRYMHi3vhA24+xTJucZGTC31p0USHMfnwnCmtfWRnNuiqunL/IHaImJKv18NuZC3 CtTMdIhtPiZZI0LpHjxoU/ONG/4x5BKHo6tOOJ3NWc8ulDAOGCyjymsywdeSZOy5 X8CQWxixVh48Xgo4OwKeexQDh0bCQtQCyqZbv2M762yFkAntpdmeaaV2CoKEAmVJ 9FVN07Oe7cdt7pUUA7Twpp45yAypOHDaOoEWSX29/Quourkr5FFGMyYd99QtJ/VA FnTweeX7v/EzbkgSEfnEDMlXEAD3Zm/3esZNczcL902H/JSSNh/00S5XFXHgEuRi X4ptEEMr/3fZ7Jet3LeMcZo6it5hwHSDTkmcmAXNSGfRCSvha8hgage277aP6UYe oBMd4qEvXd+QJw2WWtXxbZkNoYWFZopoVdoS1Fzr7LlDGgPuDNEL6qEFbAnV9UK+ l/qOOtubM2rYXwBssOxYrREDXRaKAD+qQ+ZH/y4zaA2RvH/aItS2J5SBvky/9aw7 90G6hJnX54DpzDEW/YTj =2T5D -END PGP SIGNATURE-
Bug#844650: ITP: flufl.testing -- a small collection of Python test helpers
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: flufl.testing Version : 0.1 Upstream Author : Barry Warsaw * URL : https://gitlab.com/warsaw/flufl.testing * License : ASLv2 Programming Lang: Python Description : a small collection of Python test helpers This package includes plugins for the following test tools: nose2, flake8. The plugins provide useful features (e.g. filtering tests based on a regular expression) and ensure some common coding styles (e.g. import order). They can be enabled independently. This package refactors code in the test suites of several other packages and will be used to eliminate the usual skew due to cargo culting. I will package this as part of the DMPT. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlguB4AACgkQEm61Y6dL Br/G6w/+Nb2Rxl/TsLMIHRSNjOA1wTx0OVgR+PUygn4g8M2kOzp+XxmlUwiuqcF5 VfcV55EKmq03gKEvLe+OIa/dTgwfg/tEhVaV1rw8i3PY0QETUDejeiInyVMqttgQ D5oAGAWp/9CrgYfk2AXvI/9txBbVQJzwVCKGDTk+B9RFgnGMYcESFcwSbTatQ0xB P6LQTmMCWPnWgkBQBjYmCDm68pLmlYKW4UcrXpjRdfuqMZCI5KtRr+Ulddg1gCfW Oq+o8MTST7Xu4/UYaIzdWlwXo44c8UKa81XPwSYjkEaiedX6JPzqGG3vLU6zoPNA HH2EA+sd4/vYuP/HaJrb37yTnXWlZ5JI1J9FfjO+j5J3ihPLLkQxhFLH3P+qg/Ue ce68gIE0qxqodLbEu+ceEm7B3gn56qJXaKyI3GLMIltnx899BNk5d5GkTYhStijX +HxxsM3vLY6pru3Tu/sdIeNcMX/Q8vRymr8VDV2ixcSLhfuF5kFrcUyyzcAdv1BP yKvbcXmcqqnFurwoWKLWaMNe1A0wYXiMVmQOlPHBvVhC6PEALpgZENqiygNqMfk8 pC61SyMhBojcLR5nqVdOokUrP6BkORUM/j4POOLmqUkbPjM8X7iTukm7R7AnyAC7 kioL5t3ESCzjfi5+uUkJqDHv4C+q1GiCFUBiNsNeUnOXnopt9Kk= =knJq -END PGP SIGNATURE-
Re: What to do when a maintainer is blocking maintenance for stretch?
On Nov 09, 2016, at 06:45 PM, Mattia Rizzolo wrote: >Also, a personal pledge to everybody who's reading this: please don't attach >yourself to your packages like mussels on a rock. If you realize (or >somebody else is making you realize) that you're doing a bad job on a package >*and* there is a willing adopter, just give it up; or talk to the prospective >adopter about some kind of collaboration, or something on that line. And please strongly consider team maintenance where available. Cheers, -Barry pgp0Ll3xLPIZw.pgp Description: OpenPGP digital signature
Bug#846155: ITP: python-distro -- Linux OS platform information API
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-distro Version : 1.0.1 Upstream Author : Nir Cohen * URL : https://github.com/nir0s/distro * License : ASLv2 Programming Lang: Python Description : Linux OS platform information API distro (for: Linux Distribution) provides information about the Linux distribution it runs on, such as a reliable machine-readable ID, or version information. It is a renewed alternative implementation for Python's original platform.linux_distribution function, but it also provides much more functionality which isn't necessarily Python bound like a command-line interface. This package is a new dependency for pip 9.0.1. I will maintain this package within the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhBcVftvnPZ6sHlObEm61Y6dLBr8FAlg8hjAACgkQEm61Y6dL Br9yiQ//eIBSrjI1H4H4WDcJknCJJF8Xv1OHsKqP9Kz3MDTtSgDItl/hyOzxeebs LNhiTQGe4rdrZsUFfPdcw4XPzSjsqBR5GYifEIIwzextaVwkyDNryKnM8ICeuV7B XKrLeXnc6GkPq61kf79XoJLOfTAnnbhHQQHakZhTAI4JnNSpnpi98xburu+Y3YtY eY2gVQAgfrGbwmEE3twWJh8MW0357D7LY6TnOS0mB1b09qBsNzIkDCUwsfm1zRg5 EKb39w2PUjRQVpuKWXdU96GBSMoCTMIMcOtQ9qjNlOBQ8MjWvvY1t1EKDGa/MeP1 uBPYxyZ6nxfceWf6GvL3/NIa8Gz/YdcJMJtkO1Xe3xQnP/SGOMd3PSTJ5YI4EFWR VLiQThczYKZ8U1l6yyWpR9GmojGpgslI9Pm6X0E50dM/cLvDR0mRGvxB4FUC1ie6 LZiKiHOWQ/Ta7D2TaBpTlYr418viy+lbsfZiixkzD7RVQD9gcarz3kdmbgzb/Pcq Uy9F6zYdt9X2vNgicE2SxpzGYcDTKqQ3nOg/Uic9Vxc4n5Hrzbz84o0Rb9CQzBGs QBniwko/EzPTcTWGtWI/V0OyJztcbBqa5qWeZx9QjgZIsoyk7MpOUFSnP4jCvqEF e6cERQmHnIonzDjoYfLil9siKvoDYVgtQx0t1s+kyWZnKN6fcd0= =bPTT -END PGP SIGNATURE-
Re: dput: Call for feedback: What should change? What should stay the same?
On Dec 28, 2016, at 10:25 AM, Steve Langasek wrote: >Last I looked, the dcut command in dput doesn't support the 'dm' subcommand; >this led me to switching to dput-ng when I needed it. Same here, as I recently needed to `dcut dm` allow for a maintainer of a package I had been sponsoring while he went through the process. Unfortunately, the documentation you find on extending upload permissions to DMs doesn't tell you that only dput-ng supports the dm subcommand. That's about the only difference I've noticed so far, so I'd be happy enough to switch back if dput also had a dm subcommand (although truthfully, I rarely use that anyway). I think it's fairly confusing that there's dput and dput-ng and would love to see functional and cli convergence so that eventually there's only one package that supports current use cases. Cheers, -Barry pgpJv0ozO18GG.pgp Description: OpenPGP digital signature
Re: Python 3.6 in stretch
On Jan 09, 2017, at 02:28 PM, Michael Lustfield wrote: >Python uses the microversion position for this. More importantly... is this >really a point that matters? Not really. In Debian terms you might think about the first digit as an epoch, the second digit as a major version and the third digit as a minor version. There are policies in place for deprecation cycles, and Python developers do try to maintain backward compatibility where possible. Sometimes, as per policy, things that were deprecated two major releases ago get removed, but few people noticed the deprecation, so packages break. It shouldn't be surprising, but it is. (Aside: I've ported most of my own stuff to Python 3.6 and have noticed very little breakage. Much less than porting from 3.4 to 3.5, so I'm hopeful that this transition will be easier. E.g. for GNU Mailman 3, we got bitten by a re module change that had been silently --to us-- deprecated in 3.4, but it was easily fixed.) As much as Python developers would like it otherwise, upstream library and application developers are just as overworked as we all are, so they often don't proactively test against new versions of Python until after the release. This happens every time and I just don't know what you can do about it. I think Python transitions actually demonstrate good synergy between Debian and Ubuntu. Depending on where each distro is in its cycle, a Python transition can happen in one distro or the other first, but the work always feeds back to the other, and preferably back to upstream library and application developers. Because of where we are right now, I'm hoping that Ubuntu can start doing some test rebuilds against Python 3.6 because we really don't *know* the state of the Python ecosystem until that happens. Of course, we can and do also look to other Linux distros for data, fixes, and collaboration. Cheers, -Barry pgprdEJHxJXVB.pgp Description: OpenPGP digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Jan 16, 2017, at 10:52 AM, Scott Kitterman wrote: >This is going to take a lot of work. I see random failures routinely block >migrations in Ubuntu (postfix is a current example - there's two alleged >regressions that to the extent they are valid are completely unrelated to >anything that changed in the package). > >The question is who's going to do the work? I don't see the release team >having tons of spare cycles to dive into the details of individual test >results and package failures and decide what's RC and what's not. The only >thing that scales to something the size of the Debian archive is to let the >maintainers decide. Speaking only about our experiences in Ubuntu, I can anecdotally but emphatically claim that gating promotions on passing autopkgtests has dramatically improved the quality of the running end user systems. It used to be that you had to be very careful about running and especially dist-upgrading the current devel series. You never knew if something major like the kernel or X would break, or even when minor breakages would be highly inconvenient. It just wasn't safe without a lot of precaution. But now I don't hesitate to run devel almost as soon as the new series opens. That's not to say that serious breakage never happens; not everything is tested of course, and stuff happens. But it's rare, maybe once or twice a cycle for boot-to-desktop to break, or a package regression sneaks through. I just have way way more confidence in the distro now that these tests block promotion. Yes, it can be more work at times, and it's not always easy to diagnose or reproduce promotion problems. (I'm currently flummoxed by a systemd regression triggered by a network-manager fix.) But I'd much rather have the luxury of debugging these problems on a still-functioning system and without also-frustrated users hammering me on IRC, with deadlines looming. I think it does mean that maintainers will have to step up and take more responsibility for nursing their packages through to promotion, but I also think they are in a much better position to do so than J Random User who runs an upgrade only to be left with a broken system or application. One other point. I don't know how many folks run unstable (or in Ubuntu's case, devel), but for most software I work on, few users really test pre-release versions. As much as you plead with them, "hey, beta 3 is out, please test!" they just won't for totally understandable reasons. So problems arise *after* the final release because that's when people start to really hammer on it, and integrate it with their own software, environments, and workflows. That means day-to-day user testing just can't be all that reliable because there are so few data points, and it's another reason why I think automated testing/CI is so important. (It's also an investment over time; you don't have to have 100% coverage from day one, but every new test can improve overall quality just a little bit.) It's also why I feel it's important for *me* to run unstable/devel. True, it's my day job, but I also feel a responsibility to help ensure the little corner of stuff I use, care about, and know about is in as good a shape as possible before it gets into the hands of our users. I *want* to feel the pain before they do. Cheers, -Barry pgpkRsW_JvKiI.pgp Description: OpenPGP digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Jan 16, 2017, at 06:01 PM, Ian Jackson wrote: >Right now the plan is to have _passing tests_ (well, regressionless >ones) _reduce_ the migration delay. Failing tests would be the same >as no tests. One other important point for the Ubuntu infrastructure is that the autopkgtests are a ratchet. IOW, if a test has *never* passed, its continued failure won't block promotion. It's only once a test starts passing and then regresses will it block. We have an "excuses" page that shows you what things look like. It could be prettied-up, but it provides lots of useful information. It also includes a retry button (the little three-arrow triangle) for people with the proper permissions. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html Cheers, -Barry pgpLCUAxhyn7m.pgp Description: OpenPGP digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Jan 16, 2017, at 05:45 PM, Russ Allbery wrote: >autopkgtest is useful for adding additional tests of the built binaries, >but I don't believe it's intended as a replacement for build-time testing. >Maybe I've missed something? No, I think you're exactly right. If an upstream provides unit tests, those are totally appropriate to run at build time -and to fail the build if they fail- but may not be appropriate to run in autopkgtest. autopkgtests should be reserved for larger suitability tests on the built and installed package. An example might be a Python library's test suite. It makes sense to run these at build time because that's usually when upstream will run them (i.e. during development of the package). But since the test suite usually isn't run on a built package, it shouldn't be autopkgtested. The environment for build tests and autopkgtests are importantly different, e.g. the former does not/should not allow access to the internet while the latter can and sometimes must. A good example of an autopkgtest would be an import test for a Python module, i.e. once the package is built and installed, does it import? In fact, autodep8 will automatically add import tests for Python modules in a safe way (by cd'ing to a temporary directory first). There are occasionally good reasons why an upstream's test suite can't be run at build-time, and in those few cases I will run them in an autopkgtest. But generally, I think the two are there to test different aspects or lifecycles of the package. Cheers, -Barry pgpvpsvB8j6tg.pgp Description: OpenPGP digital signature
Re: The end of OpenStack packages in Debian?
Hi Thomas, I'm very sorry to hear this, and of course I hope that everything eventually works out for you. I really appreciate the work you've done on openstack-devel packages that are useful to the wider Python community, even if sometimes there are version conflicts to work out. To that end... On Feb 15, 2017, at 07:11 PM, Ondrej Novy wrote: >> If things continue this way, I probably will ask for the removal >> of all OpenStack packages from Debian Sid after Stretch gets released >> (unless I know that someone will do the work). > >please don't ask anyone to remove __team maintained__ packages. Some of the packages on [1] could be adopted into DPMT and/or PAPT, and I would be willing to help with some of those (not the entire stack though, unfortunately). Maybe it won't come to that, but if it does, let's preserve as best we can all your great work on those packages. Cheers, -Barry [1] https://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org pgphTycGyB2fL.pgp Description: OpenPGP digital signature
Re: GitLab B.V. to host free-software GitLab for Debian project (was: debian github organization ?)
On Apr 22, 2015, at 01:25 PM, Ben Finney wrote: >Rather, this is the Debian project considering our own instance of a >first-class Git hosting platform. I guess this would mean being able to use the Debian GitLab instance for package development, rather than say Alioth? For straight-up hosting of packages already converted to git, with merge requests, I think this could be a big win. Once e.g. the Python team completes the move to git, I'd love to use features from GitLab to maintain our packages. (I'm a fan of GitLab, using it to host my own upstreams, as well as GNU Mailman 3.) What about some of the other GitLab features though? Presumably we wouldn't want issues to replace BTS. Also, how would we handle membership for things like team-maintained packages? Thanks Sytse for the generous offer. Cheers, -Barry pgpgCKkHk3SSL.pgp Description: OpenPGP digital signature
Re: git, debian/ tags, dgit - namespace proposal [and 1 more messages]
On Nov 16, 2015, at 04:52 PM, Ian Jackson wrote:
>I'm leaning towards
> archive/{debian,ubuntu,...}/
>
>This is on the grounds that the tag's semantics are that the source
>code referenced by the that is what is in the specified distro
>archive, under the specified version number.
LGTM, and I think the mapping between tag name and semantics are obvious.
Cheers,
-Barry
pgp10KcEOvPYr.pgp
Description: OpenPGP digital signature
Bug#811110: ITP: dirtbike -- convert installed Python packages to wheels
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: dirtbike Version : 0.1 Upstream Author : Asheesh Laroia * URL : https://github.com/paulproteus/dirtbike * License : Expat/MIT Programming Lang: Python Description : convert installed Python packages to wheels The purpose of this package is to make it easier to devendorize other packages which bundle various upstream packages. An example of this is pip, which bundles a half-dozen or so other upstream packages. In Debian and other distros, such vendoring is frowned upon. To make it easier to devendorize, dirtbike turns installed system packages into wheels, and these wheels can then be used instead of the vendored packages. The intent is for dirtbike to be solely a Build-Depends for a limited set of other packages such as python-pip, python-virtualenv, and any other packages which vendorize their dependencies. For now, I plan to maintain this myself (perhaps with other upstream authors who are also Debian Developers), but it may eventually migrate to the Python Applications Packaging Team (PAPT). -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWmUMBAAoJEBJutWOnSwa/lfYQAIyU7m8ZLFdqar3z9jDhnmLz cEttYUzvFFsinpyZhuoR23khyONNi0BaqNBB8ftZ5FR37G6qKtYA/BBiPv74SXxM ATXhNDrlGxbkrTpP3tem8rTIAbCy3DreJdF+ka+IXLraObnywoH0SgiICNpJBUsi M1R51GO3a/t1tsgTsnnGTXlqTDEtHJfAiqTFZDxuoPdQlIq721N0/U1QrsURRJvP d7hfJjS18R7dSWd/3giqdfwqjdNHj5CIZ2+AlloxIQBUedk+e7aiCnKy7+oI0NrN OT+y6dn1ajfpp1QKnVO8Rbxebeu7AuERxEUUGaa3BAPNczj71q/8XJ5xZTRs4pVY 0t7Cnj9T80xRY60qbGcrTifilLqI+wZ7pC1yS4JfUJWON5HvLQ/XVNd6jJtBY+4T JnJ7TY5MBnGClyFgJhH7G3eRO3fjV8NIb7zZHaIAhfokHJMTGed37ZVfdXUvDmTS zQiAJt/uw/3nyT6WL4UBiVT3pgUP1qEG9u7z3Qk891a0jIQW1HdMpQt5xdtXV0bh xltw+pgdkU07KAyS+KUwL+1OxhQM+D5JNw8mJNvo0UgvjI2WV7WO/G2/xXf5YAn1 8aZ4jG6tKd5Bp32Lq1N2WzVIXx7E5dUoGK4SKo6Gzs81rwV2AmdBlPBMTAiZkAAY A6KI8oonwFtiIIStwuED =7AwS -END PGP SIGNATURE-
Re: mkdocs locale error building djangorestframework
On Jan 26, 2016, at 01:12 AM, Ben Hutchings wrote: >That's not the problem at all. Read the error message again. Read the >source line it points to. Now look at where rv comes from: > import subprocess rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE, >... stderr=subprocess.PIPE).communicate()[0] type(rv) > For Python 3, try adding `universal_newlines=True` to any subprocess call. You'll get back a str. Cheers, -Barry pgpnuq4igREKj.pgp Description: OpenPGP digital signature
Bug#812908: ITP: python-progress -- easy progress reporting for Python
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-progress Version : 1.2 Upstream Author : Giorgos Verigakis * URL : https://github.com/verigak/progress/ * License : ISC Programming Lang: Python Description : easy progress reporting for Python License note: ISC is this OSI approved license: http://opensource.org/licenses/ISC progress is a library for displaying progress meters for command line Python applications. It is a relatively new dependency for pip, and getting progress into Debian is a blocker for updating to the latest version of pip. We do have progressbar already in Debian, but I think it's still worth getting progress in too for several reasons. One obviously is the pip dependency. Upstream pip is amenable to contributed patches for progressbar as an alternative, but this is a fair bit of work that to be honest I don't want to block on in order to get pip updated (we're woefully behind upstream here). The other reason is that it's not entirely clear which package is better supported upstream. progressbar itself appears to be stalled/abandoned upstream. While it's last PyPI entry is dated 2015-02-20, it's last upstream github commit is dated 2012-12-25. PyPI has a completely rewritten and not 100% compatible progressbar2, but getting that into Debian would require an ITP anyway. The last upload to PyPI for progress is dated 2013-11-28, but its last upstream github commit is dated today (2016-01-27) so it's clearly still active upstream, although it appears to be newly so. On balance I think it is thus worth getting progress into Debian as python-progress, for the pip dependency. I plan to maintain this package as part of the Debian Python Modules Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWqRujAAoJEBJutWOnSwa/NFYP/1bEq5I99xS4WKrsjcdFcfZX rKsZ7c1pYjg2CuKi05UKq0552Di6RopDaiXrEcZRXBCeB152yILEb7e8uu8B2zIy cW0S+nNaZ62/XSmL1/CtuDcgU117GqeFTpZaVqb0KidL/gEGrTkorstJPt2gQHrk MCtcY0Q7PEuEktKGP+3AOeZd5zEsA0AVF89QW+krsbq9XtbejJ+ElZYXuJl6qhfo znW1Sp0+nacO/AGU1wOCmBKP4YvPkjFyQT/6JF+A8jjEjbdyC680M44fLEjAtXgp 1Tcsk6kwUrEnFbCajShlZ4A0vGIc/OOKYz1Z5D8Pej7RzUXPpLYkYR0Q0dpADEpj iLBVUf8RSDB3hTgmtAr/8EjFxlqEi5VSs4UQ1WFXdOGIgaZX973V4vQou/e88Nmx xiG5Ohw9ZEEa3uKJLbOl9KESP9ghhvCLdD4n8Ji+mibwOLfc2OlUMP85MbwBeGrq 9E9ctew+xCe2b9VtslnuMH3B9lEwZLNd+s3zN7R2RNtskVd5qI48mxE6Vk9L8lUn 3XPEhD9N2IaIcf6dVznBneqSC0rqsjuWS5I/sZCtEOrZmTzWh9+D26qEmeC3jjil izv4ZfQca2+wNwrRmwbzQnTcphTjHOb0TAkMjGCCTEiNwfOsRZG+mUP2RuejWdR6 cP3Kz8Bxb2PgHcCUSCCq =Qrhp -END PGP SIGNATURE-
Re: [Mailman-Developers] Let's try to package mailman3 in Debian!
On Feb 20, 2016, at 07:52 PM, Bernhard Schmidt wrote: >- it does not work on stretch/sid because it is not compatible with > Python 3.5, see https://gitlab.com/mailman/mailman/issues/181 Since both the latest Debian and Ubuntu releases have dropped Python 3.4 and only have Python 3.5, I'm changing my mind on compatibility with Mailman 3.0.x and Python 3.5. On IRC, PEB said he was going to look at what fails when running the test suite against 3.5. If that's tractable, I'll make the upstream release-3.0 branch compatible with Python 3.5. Cheers, -Barry pgp1vsimr4AZ7.pgp Description: OpenPGP digital signature
