Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Mon, Aug 17, 2015 at 11:10:26AM -0400, Barry Warsaw wrote: > On Aug 15, 2015, at 08:24 PM, Vincent Bernat wrote: > >So, what's the situation? Should we do something during this Debconf? > JFDI. :) Yes, let's! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 15, 2015, at 08:24 PM, Vincent Bernat wrote: >So, what's the situation? Should we do something during this Debconf? JFDI. :) Cheers, -Barry pgpTGp7yyBVyt.pgp Description: OpenPGP digital signature
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
❦ 7 août 2015 12:49 -0400, Scott Kitterman : > I don't think we should just throw away all the work that's been done up to > now. So, what's the situation? Should we do something during this Debconf? -- Program defensively. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Friday, August 07, 2015 02:37:18 PM Sandro Tosi wrote: > > As someone who would really like to see the transition just get done, I > > find having this conversation now VERY frustrating. This has been > > discussed for literally more than a year including at a session at the > > last Debconf. > > > > When we were discussing git-dpm, I don't recall you objecting. > > I'm doing it now > > > To wait until > > > > the moment we are ready to pull the trigger on the migration > > are we? when was the last update on it? from an external pov, there's > not much happening on the matter > > > and demand we > > stop and reconsider the entire plan certainly feels like some kind of > > denial of service attack, even if you don't intend it this way. > > 'demand', 'denial of service attack'? I think you should re-read what > you wrote before sending it. While I can understand why you want to > exaggerate what I said, those are kinda strong words, even if sent > towards an hostile team participant. > > > There comes a point where I think the team should be able to say "the time > > for this conversation was e.g. last year" and we're going to > > proceed. > ok, can you define the 'team' then? and how it can decide when the time is > up? > > Personally, I'm pretty much a git neophyte, but I find git-dpm trivially > > easy to use and it has the property, which I think is essential, of > > producing packages for upload that have patches in debian/patches that > > are logically separated. I think it's essential because I don't think > > that one should have to refer back to a team VCS when trying to > > understand how to fix a package later (e.g. a security update). [note: > > I've no idea what other tools do or don't do this, I'm just saying this > > is an attribute of git-dpm that I find critical to any solution]. > > > > How many times should we rediscuss everything before doing this? > > talking about the 'patch regime' and a tool to codify our workflow > (which is completely unrelated to the migration) is kinda far away > from 'everything'. I don't know anything about this except what's been on IRC and this mailing list and I feel like it's been well discussed for a long time and I don't think you not paying attention means we have to start over. I'm sure that sounds harsh, but we went through all this multiple times over the last year (and no, I'm not going to waste my time looking up references to prove it, but if not, how else would I know about it - I wasn't at the last Debconf and AFAIK all the discussion has been public). I don't think we should just throw away all the work that's been done up to now. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3372435.cNn78SDtcK@kitterma-e6430
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 07, 2015, at 12:25 PM, Simon McVittie wrote: >To avoid quilt(1), I use "gbp pq" instead. What I commit to git as a >result interoperates with quilt(1), in the sense that someone like >Sandro could clone one of my repositories, manipulate the patch queue >with quilt(1), and not have to know or care that I used gbp pq; and I >could work with one of Sandro's repositories with gbp pq, without having >to deal with quilt. That seems like a nice property to have. I really wish git-pq and git-dpm could interoperate, then it really wouldn't matter which the patch management tool was chosen. Unfortunately, unless things have changed in the last year, I don't think that's the case. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807104421.016c3...@limelight.wooz.org
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 07, 2015, at 02:37 PM, Sandro Tosi wrote: >are we? when was the last update on it? from an external pov, there's >not much happening on the matter Yes, we really are. Stefano and I (mostly him) has spent a *ton* of time getting the conversion scripts working for the vast majority of packages. Stefano has put up several test repos for people to play with. There are a few packages that will have to be converted or fixed up manually for various reasons, but that's a very small number. Everything I've looked at looks great. I hope team members will have played with those repos too. I think the only reason why we haven't pulled the trigger before now is because of vacation schedules and debconf. I kind of hope that folks at debconf will JFDI . >talking about the 'patch regime' and a tool to codify our workflow >(which is completely unrelated to the migration) is kinda far away >from 'everything'. Sure, let's talk about a tool to codify our workflow! As you say, that's a completely different topic, so do start a new thread on that. There have been several attempts at pieces of that, but so far no one has pulled it all together. But, let's not let that block the migration. We've needed to do it for way too long now. We have scripts that perform the migration to a high degree of fidelity. We have test repos you can play with now to get familiar with the tools and workflow. We have some pretty good documentation which will get better over time. It's time to move on. I will say this about git-dpm vs. straight-up quilt. If you really don't like using git-dpm, then the experiment I'd like you to try is to clone some packages from Stefano's test repos, try to make some changes using only quilt. Commit those. Then see if they survive a `git-dpm checkout-patched` and `git-dpm update-patches` round-trip. If they do, then we're done. If not, why not? The point is that git-dpm makes patch management easier for most people. Some won't like it and want to use straight up quilt, but if that's a purely a local decision, then that's fine. It's not like the choice between git-dpm and git-pq because that is *not* a local decision. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807102612.5a2df...@limelight.wooz.org
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 07, 2015, at 11:30 AM, Sandro Tosi wrote: >ehm.. Since you havent tried to create a perl package with >dh-make-perl, I guess you missed much of its functionalities, like: > >* it downloads the tarball from CPAN >* it populates the debian/ files with the information from module >metadata (not all that crap that dh_make does) >** it fetches the ITP bug number from BTS >** setup all b-d and deps in d/control (ok, for deps we have >dh_python*), Vcs fields, short and long descriptions and so on: it is >basically ready with just 1 or 2 changes >** create a very precise d/copyright (it will still need a manual >check, but names, years, licenses are there) >* all of these creating a git repo with the standards pkg-perl defined. > >that's almost all we have to do by hand; i was positively shocked when >I used it the first time. Two questions: is any of that applicable to Python? Is any of that precluded by a migration to git and git-dpm? Meaning, sure that sounds like a cool tool to have but we'd probably have to adapt the Perl tool or write our own Pythonic one, and I don't get how that in any way influences our switch to git. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150807100813.75a45...@limelight.wooz.org
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
> As someone who would really like to see the transition just get done, I find > having this conversation now VERY frustrating. This has been discussed for > literally more than a year including at a session at the last Debconf. > > When we were discussing git-dpm, I don't recall you objecting. I'm doing it now > To wait until > the moment we are ready to pull the trigger on the migration are we? when was the last update on it? from an external pov, there's not much happening on the matter > and demand we > stop and reconsider the entire plan certainly feels like some kind of denial > of service attack, even if you don't intend it this way. 'demand', 'denial of service attack'? I think you should re-read what you wrote before sending it. While I can understand why you want to exaggerate what I said, those are kinda strong words, even if sent towards an hostile team participant. > There comes a point where I think the team should be able to say "the time for > this conversation was e.g. last year" and we're going to proceed. ok, can you define the 'team' then? and how it can decide when the time is up? > Personally, I'm pretty much a git neophyte, but I find git-dpm trivially easy > to use and it has the property, which I think is essential, of producing > packages for upload that have patches in debian/patches that are logically > separated. I think it's essential because I don't think that one should have > to refer back to a team VCS when trying to understand how to fix a package > later (e.g. a security update). [note: I've no idea what other tools do or > don't do this, I'm just saying this is an attribute of git-dpm that I find > critical to any solution]. > > How many times should we rediscuss everything before doing this? talking about the 'patch regime' and a tool to codify our workflow (which is completely unrelated to the migration) is kinda far away from 'everything'. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxz9xdxayyhq3utkzqtzftu7dabvn0asq3htgcfg8na...@mail.gmail.com
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Friday, August 07, 2015 11:30:11 AM Sandro Tosi wrote: > On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw wrote: > > On Aug 06, 2015, at 11:42 AM, Sandro Tosi wrote: > >>no I mean, really, read http://pkg-perl.alioth.debian.org/git.html > >> > > Thanks for the link Sandro. > > > > Reading this, I think it's on par with our > > https://wiki.debian.org/Python/GitPackaging by which I mean it's > > prescriptive of how to do common tasks in a team collaborative way, but > > neither document really provides much rationale on *why* those particular > > recipes were chosen. > pkg-perl migration to git happened quite some time ago, so I guess > there were not many tools to choose from at that time (but if someone > is interested in the why, I imagine in their ml archives there will be > answers) > > >>* they have a tool that automatically creates (and push) a new package > >>from CPAN, and sets everything up with the team standards; the same > >>should happen for python and pypi. and there is tool (dpt) to manage > >>the other common packaging tasks > >> > > Certainly we could do the same, but TBH, with a working d/watch file, I've > > never much found it necessary. What I'd actually like is for `git-dpm > > import-new-upstream` to take no-args and then do a uscan to get the > > orig.tar in that case. That seems like it would be a fairly simple > > patch. > > ehm.. Since you havent tried to create a perl package with > dh-make-perl, I guess you missed much of its functionalities, like: > > * it downloads the tarball from CPAN > * it populates the debian/ files with the information from module > metadata (not all that crap that dh_make does) > ** it fetches the ITP bug number from BTS > ** setup all b-d and deps in d/control (ok, for deps we have > dh_python*), Vcs fields, short and long descriptions and so on: it is > basically ready with just 1 or 2 changes > ** create a very precise d/copyright (it will still need a manual > check, but names, years, licenses are there) > * all of these creating a git repo with the standards pkg-perl defined. > > that's almost all we have to do by hand; i was positively shocked when > I used it the first time. > > > Afaict, dpt is a tool sitting in a special git repo, not even in the > > archive. So it's a non-standard thing that members of the Perl team will > > have to install and learn and while you could claim that git-dpm is also > > such a tool, it's 1) in the archive; 2) not at all specialized toward > > Python. > > does it matter? git-dpm has currently 214 installation (source > Popcon), kinda low for a package mirrored everywhere, but in line with > the expectation for a DD/DM tool. the Debian archive is for our users, > not necessarily for all development/infrastructure tools. dpt is an > implementation of pkg-perl team workflow, so how is it better to have > a wiki page with all the commands to cut&paste than a program that > does exactly the same without the risk of the "smart" guy who thinks > "I know what to do without reading the wiki" and deviates from our > standards? > > > In any case, it's still Another Tool To Learn. > > we have tons of tools to learn anyway, and this is just a helper for > our workflow (so it does basic/routine packaging tasks how *we* want > them), i honestly dont see the problem here. > > >>* they do not force as default the use of an unnecessarily convoluted > >>"patch regime" - just stick to the path of least resistance, quilt > >>unapplied-patches is perfectly usable with git and is a method every > >>one can use (and should know anyway), without tying the patch to the > >>SCM tool we are using > >> > > But, is that a good thing? quilt itself is a PITA to use IMHO, and I find > > it > I guess https://upsilon.cc/~zack/stuff/dpkg-v3/ proves differently, ie > a lot of people seems to appreciate quilt (I know that 3.0 (quilt) > doesnt necessarily reflect in using quilt). It's not perfect but I > find it usable and in line with the style of other packaging tools. > > > very nice that with git-dpm, once you're switched to the patches branch, > > all you have to know is git commands. You modify the upstream source in > > place, and git commit to your heart's content. If you must, `git rebase > > -i` and do other git-y things without having to worry about quilt > > refreshing, making sure your patches are created at the correct > > patch-level, dealing with rejections, push, pop, quilt apply -f, and > > other such crazy stuff when the patches don't apply, etc. > > so one needs to be a git master to apply patches to a debian package? > and completly ignoring the standard way debian decides to use (quilt)? > > I dont want to be forced to use git-dpm just because you dislike quilt > and you are so vehemently pushing for git-dpm no one else bothers to > say something different. You wanna use it? sure, but that doesnt mean > it has to be the default for all our packages. the default has to be > the minimum common ground anyone in th
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On 07/08/15 11:30, Sandro Tosi wrote: > On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw wrote: >> But, is that a good thing? quilt itself is a PITA to use IMHO > > a lot of people seems to appreciate quilt (I know that 3.0 (quilt) > doesnt necessarily reflect in using quilt). It's not perfect but I > find it usable and in line with the style of other packaging tools. I agree with Sandro about repository contents while disagreeing about the quilt(1) command-line tool, which is perhaps an interesting perspective. I avoid quilt(1) wherever possible, and whenever I use it to resolve some weird patch-queue corner case, I have to look up how it works. However, the patch-queue format, and patches-unapplied git repository contents, make a lot of sense to me: the git history contains exactly the parts that don't get rebased. To avoid quilt(1), I use "gbp pq" instead. What I commit to git as a result interoperates with quilt(1), in the sense that someone like Sandro could clone one of my repositories, manipulate the patch queue with quilt(1), and not have to know or care that I used gbp pq; and I could work with one of Sandro's repositories with gbp pq, without having to deal with quilt. That seems like a nice property to have. (Example repositories: dbus, ioquake3) S -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c495bb.4010...@debian.org
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw wrote: > On Aug 06, 2015, at 11:42 AM, Sandro Tosi wrote: > >>no I mean, really, read http://pkg-perl.alioth.debian.org/git.html > > Thanks for the link Sandro. > > Reading this, I think it's on par with our > https://wiki.debian.org/Python/GitPackaging by which I mean it's prescriptive > of how to do common tasks in a team collaborative way, but neither document > really provides much rationale on *why* those particular recipes were chosen. pkg-perl migration to git happened quite some time ago, so I guess there were not many tools to choose from at that time (but if someone is interested in the why, I imagine in their ml archives there will be answers) >>* they have a tool that automatically creates (and push) a new package >>from CPAN, and sets everything up with the team standards; the same >>should happen for python and pypi. and there is tool (dpt) to manage >>the other common packaging tasks > > Certainly we could do the same, but TBH, with a working d/watch file, I've > never much found it necessary. What I'd actually like is for `git-dpm > import-new-upstream` to take no-args and then do a uscan to get the orig.tar > in that case. That seems like it would be a fairly simple patch. ehm.. Since you havent tried to create a perl package with dh-make-perl, I guess you missed much of its functionalities, like: * it downloads the tarball from CPAN * it populates the debian/ files with the information from module metadata (not all that crap that dh_make does) ** it fetches the ITP bug number from BTS ** setup all b-d and deps in d/control (ok, for deps we have dh_python*), Vcs fields, short and long descriptions and so on: it is basically ready with just 1 or 2 changes ** create a very precise d/copyright (it will still need a manual check, but names, years, licenses are there) * all of these creating a git repo with the standards pkg-perl defined. that's almost all we have to do by hand; i was positively shocked when I used it the first time. > Afaict, dpt is a tool sitting in a special git repo, not even in the archive. > So it's a non-standard thing that members of the Perl team will have to > install and learn and while you could claim that git-dpm is also such a tool, > it's 1) in the archive; 2) not at all specialized toward Python. does it matter? git-dpm has currently 214 installation (source Popcon), kinda low for a package mirrored everywhere, but in line with the expectation for a DD/DM tool. the Debian archive is for our users, not necessarily for all development/infrastructure tools. dpt is an implementation of pkg-perl team workflow, so how is it better to have a wiki page with all the commands to cut&paste than a program that does exactly the same without the risk of the "smart" guy who thinks "I know what to do without reading the wiki" and deviates from our standards? > In any case, it's still Another Tool To Learn. we have tons of tools to learn anyway, and this is just a helper for our workflow (so it does basic/routine packaging tasks how *we* want them), i honestly dont see the problem here. >>* they do not force as default the use of an unnecessarily convoluted >>"patch regime" - just stick to the path of least resistance, quilt >>unapplied-patches is perfectly usable with git and is a method every >>one can use (and should know anyway), without tying the patch to the >>SCM tool we are using > > But, is that a good thing? quilt itself is a PITA to use IMHO, and I find it I guess https://upsilon.cc/~zack/stuff/dpkg-v3/ proves differently, ie a lot of people seems to appreciate quilt (I know that 3.0 (quilt) doesnt necessarily reflect in using quilt). It's not perfect but I find it usable and in line with the style of other packaging tools. > very nice that with git-dpm, once you're switched to the patches branch, all > you have to know is git commands. You modify the upstream source in place, > and git commit to your heart's content. If you must, `git rebase -i` and do > other git-y things without having to worry about quilt refreshing, making sure > your patches are created at the correct patch-level, dealing with rejections, > push, pop, quilt apply -f, and other such crazy stuff when the patches don't > apply, etc. so one needs to be a git master to apply patches to a debian package? and completly ignoring the standard way debian decides to use (quilt)? I dont want to be forced to use git-dpm just because you dislike quilt and you are so vehemently pushing for git-dpm no one else bothers to say something different. You wanna use it? sure, but that doesnt mean it has to be the default for all our packages. the default has to be the minimum common ground anyone in the team is able to use. and quilt is the default tool for patches, trying to hide it generates just pain. > If you say that patch stack management is a PITA either way, I won't argue. :) > But I do think it's generally easier when staying in git as long as
Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 06, 2015, at 11:42 AM, Sandro Tosi wrote: >no I mean, really, read http://pkg-perl.alioth.debian.org/git.html Thanks for the link Sandro. Reading this, I think it's on par with our https://wiki.debian.org/Python/GitPackaging by which I mean it's prescriptive of how to do common tasks in a team collaborative way, but neither document really provides much rationale on *why* those particular recipes were chosen. >* they have a tool that automatically creates (and push) a new package >from CPAN, and sets everything up with the team standards; the same >should happen for python and pypi. and there is tool (dpt) to manage >the other common packaging tasks Certainly we could do the same, but TBH, with a working d/watch file, I've never much found it necessary. What I'd actually like is for `git-dpm import-new-upstream` to take no-args and then do a uscan to get the orig.tar in that case. That seems like it would be a fairly simple patch. Afaict, dpt is a tool sitting in a special git repo, not even in the archive. So it's a non-standard thing that members of the Perl team will have to install and learn and while you could claim that git-dpm is also such a tool, it's 1) in the archive; 2) not at all specialized toward Python. In any case, it's still Another Tool To Learn. >* they do not force as default the use of an unnecessarily convoluted >"patch regime" - just stick to the path of least resistance, quilt >unapplied-patches is perfectly usable with git and is a method every >one can use (and should know anyway), without tying the patch to the >SCM tool we are using But, is that a good thing? quilt itself is a PITA to use IMHO, and I find it very nice that with git-dpm, once you're switched to the patches branch, all you have to know is git commands. You modify the upstream source in place, and git commit to your heart's content. If you must, `git rebase -i` and do other git-y things without having to worry about quilt refreshing, making sure your patches are created at the correct patch-level, dealing with rejections, push, pop, quilt apply -f, and other such crazy stuff when the patches don't apply, etc. If you say that patch stack management is a PITA either way, I won't argue. :) But I do think it's generally easier when staying in git as long as possible, and dealing with other-tool peculiarities only at the boundaries. >* you can choose more complex ways to do things, but not as the default >(because -you know- you want us to buy the story "if we migrate to git, >hordes of contributors will come", then keep the process as simple as >possible, and be flexible to more skilled maintainers if they want to) That's not necessarily why *I* want to switch to git. I think it's more or less a myth that the migration to git suddenly increases the volume or quality of contributions. I want us to switch to git because git is just a better vcs than svn, for reasons I don't need to explain to anybody. Switching to git will make the *current* DPMT members lives easier, and if it reduces friction so more people will come to help us, bonus! >* they have a way to download all the packages and do mass-commit on them Which isn't impossible for us either, IIUC. I think mr would work for us after switching to git-dpm too, though I have not used it much and very rarely have ever wanted to do a mass commit (updated d/watch to use the redirector was the first time I thought, hmm, I'd love to mass commit that change). >they manage more than 3k packages, their approach works in practice >and scales, do we really need to reinvent the wheel here? I don't think we're reinventing the wheel! We're using just a few common tools and a pile of policy. In fact, we'll be using *fewer* tools that the Perl team (i.e. just git and git-dpm). No need for a special additional dpt tool, no need for quilt, and not preventing the use of conveniences like mr. I even think we're going to have less complex recipes and policies than the Perl team. >(as I'm quite sure at debconf there will be discussion about it, this >my input on the matter) Thanks for that! I won't be at Debconf this year, and if team members are there and the conversion is discussed, I hope summaries will be posted. We had some very thorough discussions at last year's Debconf, followed by lengthy discussions on the mailing list (and even some at Pycon), and through much hard work by folks like Stefano, now we're very close to flag day. I won't say that decisions are set in stone - I don't even have any authority to say that. IMHO, consensus, and those-who-do-the-work, rules. But I do hope we don't go back to square one. I think we're fairly well convinced that if git-dpm turns out to not be the right tool, we'll still have converted to git, and we can implement some other better workflow later. I still like git-dpm a lot, but we're not closing any future doors. (One interesting thing I've learned since last year, reading recent debian-devel th
so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
no I mean, really, read http://pkg-perl.alioth.debian.org/git.html * they have a tool that automatically creates (and push) a new package from CPAN, and sets everything up with the team standards; the same should happen for python and pypi. and there is tool (dpt) to manage the other common packaging tasks * they do not force as default the use of an unnecessarily convoluted "patch regime" - just stick to the path of least resistance, quilt unapplied-patches is perfectly usable with git and is a method every one can use (and should know anyway), without tying the patch to the SCM tool we are using * you can choose more complex ways to do things, but not as the default (because -you know- you want us to buy the story "if we migrate to git, hordes of contributors will come", then keep the process as simple as possible, and be flexible to more skilled maintainers if they want to) * they have a way to download all the packages and do mass-commit on them they manage more than 3k packages, their approach works in practice and scales, do we really need to reinvent the wheel here? (as I'm quite sure at debconf there will be discussion about it, this my input on the matter) -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxxcakhj9wdb_q1cnkdi4q1gex7sd4ir+o2wjn6vhub...@mail.gmail.com
