Re: git migration (AKA missing old good svn days)
❦ 29 septembre 2015 23:05 +0200, Piotr Ożarowski : >> Yes, let's discourage any new packages from manually migrating or starting >> out >> in git just until flag day. But I'm not sure it's worth removing DPMT on >> existing repos just to add it back, hopefully RSN. > > we agreed to something - 1 package per person, just for tests, with > reports sent to this mailing list. Can you point me to a single > report? I may have missed this announce. What's the message ID? -- Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"] signature.asc Description: PGP signature
Re: lintian and team uploads
On Tuesday, September 29, 2015 10:31:23 PM Julien Puydt wrote: > Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit : > > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote: > > >(and remember to remove DPMT from debian/control if it's not in SVN ;P) > > > > Given that the final git migration is imminent (really! otherwise I'm > > going to scream ;), can we not force people to go through this churn > > right now? > Indeed, I find that offensive : if git is a better tool than subversion, > and if it's going to be used, what's the point? > > > Yes, let's discourage any new packages from manually migrating or starting > > out in git just until flag day. But I'm not sure it's worth removing > > DPMT on existing repos just to add it back, hopefully RSN. > > I would like to make some points clear: > 1. I wouldn't have contributed a single package in subversion, as it's just > too cumbersome to use. I liked svn when it replaced cvs, but not so much > since I started using git. > 2. When I saw the DPMT policy mentioned only subversion, I asked around > (can't remember if it was just on IRC or on this ml) and was told it was ok > to use git since the migration was bound to happen sooner or later. > 3. Afterwards, being just a DM, I sent RFS mails through this very list in > which I generally gave the Vcs-* fields from the d/control files, which > clearly showed I used git : no complaint about it. > 4. Those package got sponsored without complaint about it either. > > So you'll understand that getting flames (even with smileys) about it > now is quite annoying. > > I still have a series of things I plan to package for Debian ; those are > Python Modules, and I'll use git. If that's a problem for the Debian > Python Modules Team, can you point me to a more appropriate team? Just chill out and have a little patience. What VCS gets used just doesn't make that much different for most things we need to do. If you can't bring yourself to commit to svn, then just have a bit of patience. Scott K
Re: lintian and team uploads
On Tuesday, September 29, 2015 04:48:09 PM Barry Warsaw wrote: > On Sep 29, 2015, at 10:31 PM, Julien Puydt wrote: > >I still have a series of things I plan to package for Debian ; those are > >Python Modules, and I'll use git. If that's a problem for the Debian > >Python Modules Team, can you point me to a more appropriate team? > > This illustrates my concern. We've already had defections from the team > because of the prohibition against git. Once gone from the team, it will be > difficult to bring them back into the fold. I would like to be creating > *more* collaboration, not less, otherwise, what's the point of having a > team? We don't have a prohibition against git. We have a prohibition against using multiple repositories. Once we switch to git, it'll be svn gets prohibited. The thing that needs doing is whatever's blocking you and tumbleweed from pulling the trigger on the migration. Scott K
Re: git migration (AKA missing old good svn days)
On Tuesday, September 29, 2015 11:05:19 PM Piotr Ożarowski wrote: > [Barry Warsaw, 2015-09-29] > > > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote: > > >(and remember to remove DPMT from debian/control if it's not in SVN ;P) > > > > Given that the final git migration is imminent (really! otherwise I'm > > going to scream ;), can we not force people to go through this churn > > right now? > but it's OK to force others to search for repo location, used workflow, > tool, naming convention, etc? > > > Yes, let's discourage any new packages from manually migrating or starting > > out in git just until flag day. But I'm not sure it's worth removing > > DPMT on existing repos just to add it back, hopefully RSN. > > we agreed to something - 1 package per person, just for tests, with > reports sent to this mailing list. Can you point me to a single report? > Can you point me to a single person who converted only one package? > Are you sure everyone uses the same workflow? > > I don't like it, I don't like it at all and that's why I complain and > that's why I don't sponsor such packages. I did do tests. I never pushed the results to alioth since I didn't really see a point at the time. I gave feedback on the list that resulted in changes to the team git-dpm configurations so the correct tag format would be used. Maybe some other stuff too. Scott K
Re: git migration (AKA missing old good svn days)
On Sep 29, 2015, at 11:05 PM, Piotr Ożarowski wrote: >but it's OK to force others to search for repo location, used workflow, >tool, naming convention, etc? No, definitely not! We have the svn we all know and love , and if it's not there, then it can only otherwise be in git with the workflow and set up we're about to move to, which is defined here: https://wiki.debian.org/Python/GitPackaging No other choices. Once the migration completes, it's only the git workflow. (And debcheckout should DTRT if there's been at least one upload in git.) >> Yes, let's discourage any new packages from manually migrating or starting >> out in git just until flag day. But I'm not sure it's worth removing DPMT >> on existing repos just to add it back, hopefully RSN. > >we agreed to something - 1 package per person, just for tests, with >reports sent to this mailing list. Can you point me to a single report? >Can you point me to a single person who converted only one package? >Are you sure everyone uses the same workflow? > >I don't like it, I don't like it at all and that's why I complain and >that's why I don't sponsor such packages. I totally understand. It hasn't gone as smoothly or as quickly as anybody wanted, but we do know where we're going to end up. I'm willing to do whatever it takes to get us to the final goal, and then all this will be moot. TOOWTDI. Cheers, -Barry
git migration (AKA missing old good svn days)
[Barry Warsaw, 2015-09-29] > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote: > > >(and remember to remove DPMT from debian/control if it's not in SVN ;P) > > Given that the final git migration is imminent (really! otherwise I'm going to > scream ;), can we not force people to go through this churn right now? but it's OK to force others to search for repo location, used workflow, tool, naming convention, etc? > Yes, let's discourage any new packages from manually migrating or starting out > in git just until flag day. But I'm not sure it's worth removing DPMT on > existing repos just to add it back, hopefully RSN. we agreed to something - 1 package per person, just for tests, with reports sent to this mailing list. Can you point me to a single report? Can you point me to a single person who converted only one package? Are you sure everyone uses the same workflow? I don't like it, I don't like it at all and that's why I complain and that's why I don't sponsor such packages. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: lintian and team uploads
On Sep 29, 2015, at 10:31 PM, Julien Puydt wrote: >I still have a series of things I plan to package for Debian ; those are >Python Modules, and I'll use git. If that's a problem for the Debian >Python Modules Team, can you point me to a more appropriate team? This illustrates my concern. We've already had defections from the team because of the prohibition against git. Once gone from the team, it will be difficult to bring them back into the fold. I would like to be creating *more* collaboration, not less, otherwise, what's the point of having a team? Cheers, -Barry
Re: lintian and team uploads
Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit : > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote: > > >(and remember to remove DPMT from debian/control if it's not in SVN ;P) > > Given that the final git migration is imminent (really! otherwise I'm going to > scream ;), can we not force people to go through this churn right now? Indeed, I find that offensive : if git is a better tool than subversion, and if it's going to be used, what's the point? > Yes, let's discourage any new packages from manually migrating or starting out > in git just until flag day. But I'm not sure it's worth removing DPMT on > existing repos just to add it back, hopefully RSN. I would like to make some points clear: 1. I wouldn't have contributed a single package in subversion, as it's just too cumbersome to use. I liked svn when it replaced cvs, but not so much since I started using git. 2. When I saw the DPMT policy mentioned only subversion, I asked around (can't remember if it was just on IRC or on this ml) and was told it was ok to use git since the migration was bound to happen sooner or later. 3. Afterwards, being just a DM, I sent RFS mails through this very list in which I generally gave the Vcs-* fields from the d/control files, which clearly showed I used git : no complaint about it. 4. Those package got sponsored without complaint about it either. So you'll understand that getting flames (even with smileys) about it now is quite annoying. I still have a series of things I plan to package for Debian ; those are Python Modules, and I'll use git. If that's a problem for the Debian Python Modules Team, can you point me to a more appropriate team? Snark on #debian-python
Re: Bug#798999: transition: python3.5 supported
Dnia 2015-09-27, nie o godzinie 10:28 -0400, Scott Kitterman pisze: [ cut ] > Yes. They have started. I think we're about a third of the way > through Dependency level 1. Numpy is in Dependency level 5, so this > is not unexpected for now. You can follow the progress in the > transition tracker [1]. > Can I ask to not automatically rebuild PyOpenCL? I'll rebuild and upload it myself, with few fixes. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Re: lintian and team uploads
On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote: >(and remember to remove DPMT from debian/control if it's not in SVN ;P) Given that the final git migration is imminent (really! otherwise I'm going to scream ;), can we not force people to go through this churn right now? Yes, let's discourage any new packages from manually migrating or starting out in git just until flag day. But I'm not sure it's worth removing DPMT on existing repos just to add it back, hopefully RSN. Cheers, -Barry
lintian and team uploads
[Julien Puydt, 2015-09-29] > Yes, that's what I said: I put myself as uploaders so lintian > doesn't bug me about NMU. my guess¹ is that you used different name/email in debian/control and debian/changelog [¹] and it's the last one, include pointer to sources next time (and remember to remove DPMT from debian/control if it's not in SVN ;P) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Le mardi 29 sept. 2015 à 20:40:11 (+0200), Piotr Ożarowski a écrit : > [Barry Warsaw, 2015-09-29] > > On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: > > > > >- I want lintian not to bug me about NMU ; > > > > This one's easy. Just put "Team upload" in the changelog (e.g. `dch > > --team`). > > it's even easier than that... add yourself to Uploaders (you're > maintaining it after all!) Yes, that's what I said: I put myself as uploaders so lintian doesn't bug me about NMU. Snark on #debian-python
Re: Suggestion for recommended build tools a python application
Hi, Le mercredi 30 sept. 2015 à 00:17:32 (+0600), Titon Barua a écrit : > I found some online resource where someone suggested using autotools for > building GTK+python applications. I can definitely go that route, but how > would it affect packaging for debian? How am I supposed to specify the > python module dependencies? With autotools, you can check python deps using the AC_CHECK_PYTHON_MODULE macro, which you can for example find here: http://anonscm.debian.org/cgit/debian-science/packages/sagemath.git/tree/debian/pruner/m4/python_module.m4 Snark on #debian-python
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Barry Warsaw, 2015-09-29] > On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: > > >- I want lintian not to bug me about NMU ; > > This one's easy. Just put "Team upload" in the changelog (e.g. `dch --team`). it's even easier than that... add yourself to Uploaders (you're maintaining it after all!) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Maintainer vs. Uploaders
On Sep 29, 2015, at 04:30 PM, Piotr Ożarowski wrote: >Maintainer vs Uploaders rules needs to be moved to policy. I will >propose a patch to the policy soon (I'd prefer a native speaker to do >it, though) +1, and I'd be happy to review the specific text. Cheers, -Barry
Suggestion for recommended build tools a python application
Hi, I am developing a plugin for IBus, written in python3. The project depends on some other python modules and system packages, like python3-gi, gir1.2-ibus-1.0 etc. Also, it needs to install data files to the system ( inside /usr/lib/ibus/component/) to make itself available to IBus. I am a debian user and the project being debian packaging friendly is an important goal. As far as my project requirements go, I can't use any of the distutils/setuptools/distribute since they can't handle dependency checks not satiable through PyPI ( ridiculous isn't it? ). I can't also dive into the absurdity of making a `wheel` and installing it with `pip` since wheels don't allow file deployment in absolute system path. I found some online resource where someone suggested using autotools for building GTK+python applications. I can definitely go that route, but how would it affect packaging for debian? How am I supposed to specify the python module dependencies? I've done some research on 'dh' with 'pybuild', but it seems to be concerned with packaging python projects using in distutils family tools. Right now, my project has a custom installer script that asks the users to install necessary packages and copies the files to the appropriate location. I would gladly appreciate if anyone can guide to a saner alternative. - Titon [ Sorry for overwhelming you guys with questions. I love python, but I absolutely despise being a back-end server side application developer who writes in python; every bit of productivity gained by the language is usually lost in pulling out hairs in times of deployment and system integration. ]
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: >- I want lintian not to bug me about NMU ; This one's easy. Just put "Team upload" in the changelog (e.g. `dch --team`). Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Hi, Le mardi 29 sept. 2015 à 09:48:16 (-0400), Barry Warsaw a écrit : > On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote: > > >Once again, the python policy about Maintainer/Uploaders has been ignored > > > >either policy changes or this has to stop at some point. > > A few observations. > > The policy should perhaps be better promoted or more explicitly written. The > links you provided are useful, but I wonder whether they are easily > overlooked, forgotten, or misinterpreted. > > Policy doesn't really spell out the operational differences for when the team > is Maintainer vs. Uploader, and the wiki page explicitly says it's an > *unwritten* policy (despite the fact that putting it in the wiki probably > qualifies as "written" :). How should the change be acknowledged by the > maintainer? Should I Cc the mailing list when I contact the maintainer? Is > it okay to commit to vcs but not upload? How long do you wait for feedback > before you can do the upload? I'm just a DM, but I'm still in the team, so I think I can state my opinion, and explain how I would do things. First thing, report a bug on the package (request for a new version, for example). Wait. Provide patches. Wait. Second, contact the maintainer off list&bug. Wait. Third, contact the list and put the maintainer in CC, stating that things don't get further fast enough and you would like the team to get involved. Wait. Fourth, if the maintainer hasn't answered, then proceed with an RFS or upload (depending on whether one is DD or DM). > (Aside: git! I would love to be able to commit and push a branch and then ask > for the maintainer to review, merge, and upload - or give me the green light > to go ahead.) I create all my packages in git -- that's what the debian-science team uses. And I consider the fact that a package is subversion-maintained a hindrance. > Should we have some automated tools to help out here? I'm not sure where to > hook in such a tool, but if for example when I build a source package, I got a > nice little lintian-like warning saying "The package is team uploadable but > not team maintained, did you give the maintainer time to respond to your > issue?" Something like that would go a long way toward mitigating accidental > or careless toe-stepping. Oh dear, another lintian output to bother me! And don't call that a "warning", some sensitive people prefer the word "tag" :-P > Do all team members understand the implications when they set the two fields? > Some maintainers may not really care and may have been less conscientious > about setting the fields. I definitely didn't really understand the implications. I put the DPMT as maintainer and myself as uploader because : - I want lintian not to bug me about NMU ; - I want to make clear I won't consider people are stepping on my toes if they start helping with a package. Cheers, Snark on #debian-python
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Sep 29, 2015, at 02:02 PM, Tristan Seligmann wrote: >After reading this thread, I feel like I should go through all of my >packages and remove the team from Maintainer for all of them. I try very >hard to respond promptly to pings (bugs, email, IRC, ...) about my >packages, even if it's just to say "sorry, I can't take care of that right >now, feel free to upload"; but I'm not sure that having someone blindly >upload my packages if they haven't worked on them before is a good idea. I'm willing to deal with some honest mistakes with my packages in order to foster a vibrant and active community. I am happy to answer questions about my packages, but I feel spoiled by how nicely things work as an upstream with code hosting sites like GitLab. If we had merge requests, online and email reviews, one-click auto-merge (and uploads!) I think we'd have a better team collaboration workflow. Even post-commit/upload emailed diffs would at least let me review changes after the fact, so I could repair things if I noticed a big problem. Cheers, -Barry
Maintainer vs. Uploaders
[Barry Warsaw, 2015-09-29] > How should the change be acknowledged by the > maintainer? Should I Cc the mailing list when I contact the maintainer? Is do we really need a written policy how to contact fellow co-maintainer? Ping on IRC, send an email, send a message via xmpp or phone, ... use whatever you usually use to contact any other Debian maintainer. An example message: "I just commited some changes in foo related to bar. Please take a look, I plan to upload it to unstable in a day or two. Let me know if I should wait a bit longer or if you're not OK with these changes. Thanks" I think such message to all Uploaders who clearly know more about given package than I do is a good practice even if team is listed in Maintainer field. I don't think sending such message after fixing a typo is needed, but it's definitely a must when someone replaces dh with cdbs or vice versa. > it okay to commit to vcs but not upload? How long do you wait for feedback > before you can do the upload? yes, it's always OK to commit changes (which can be reverted). It's not OK to force someone else to maintain these changes by uploading it. > Should we have some automated tools to help out here? I'm not sure where to no, we already have -commits mailing list which nobody reads. Yet another reason why team should be in Uploaders and not in Maintainer field. > Do all team members understand the implications when they set the two fields? > Some maintainers may not really care and may have been less conscientious > about setting the fields. Maintainer vs Uploaders rules needs to be moved to policy. I will propose a patch to the policy soon (I'd prefer a native speaker to do it, though) > The wiki says that the general rule of thumb is to set the team as Maintainer, > to which I agree. I don't (due to "package and forget" issue) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tue, 29 Sep 2015 at 15:48 Barry Warsaw wrote: > The wiki says that the general rule of thumb is to set the team as > Maintainer, > to which I agree. I may not have been as deliberate about my own > packages, so > I plan on reviewing them, and will fix any that aren't "special". > After reading this thread, I feel like I should go through all of my packages and remove the team from Maintainer for all of them. I try very hard to respond promptly to pings (bugs, email, IRC, ...) about my packages, even if it's just to say "sorry, I can't take care of that right now, feel free to upload"; but I'm not sure that having someone blindly upload my packages if they haven't worked on them before is a good idea. (And I say this having done a few team uploads in DPMT / collab-maint recently; while I didn't think too much about these at the time, in retrospect I feel like I made a mistake uploading those packages)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote: >Once again, the python policy about Maintainer/Uploaders has been ignored > >either policy changes or this has to stop at some point. A few observations. The policy should perhaps be better promoted or more explicitly written. The links you provided are useful, but I wonder whether they are easily overlooked, forgotten, or misinterpreted. Policy doesn't really spell out the operational differences for when the team is Maintainer vs. Uploader, and the wiki page explicitly says it's an *unwritten* policy (despite the fact that putting it in the wiki probably qualifies as "written" :). How should the change be acknowledged by the maintainer? Should I Cc the mailing list when I contact the maintainer? Is it okay to commit to vcs but not upload? How long do you wait for feedback before you can do the upload? (Aside: git! I would love to be able to commit and push a branch and then ask for the maintainer to review, merge, and upload - or give me the green light to go ahead.) Should we have some automated tools to help out here? I'm not sure where to hook in such a tool, but if for example when I build a source package, I got a nice little lintian-like warning saying "The package is team uploadable but not team maintained, did you give the maintainer time to respond to your issue?" Something like that would go a long way toward mitigating accidental or careless toe-stepping. Do all team members understand the implications when they set the two fields? Some maintainers may not really care and may have been less conscientious about setting the fields. The wiki says that the general rule of thumb is to set the team as Maintainer, to which I agree. I may not have been as deliberate about my own packages, so I plan on reviewing them, and will fix any that aren't "special". Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On September 29, 2015 7:55:36 AM EDT, Julien Cristau wrote: >On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote: > >> Once again, the python policy about Maintainer/Uploaders has been >ignored >> >> >http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership >> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin >> >> either policy changes or this has to stop at some point. >> >OTOH, this is experimental. It's not like this upload has any effect >on >anyone except to let Thomas work on packages that depend on it. Are >there any specific changes you object to, and that can't be easily >reverted before an upload to unstable? It's also not much effort to do a bit of coordination with the team. The technical impact of this kind of antisocial behavior is, IMO, secondary. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
> OTOH, this is experimental. It's not like this upload has any effect on > anyone except to let Thomas work on packages that depend on it. still the policy defines a set of rules that apply to any debian suites, or are you suggesting that experimental is not cover by those rules and we could do whatever we want? The bug asking for a new version was issues 2 hours before the upload with urgency wishlist, without mentioning it was a blocker for anything. > Are > there any specific changes you object to As for the technical aspects, tests were disabled mentioning they access internet (and from the code it is not clear at all if they do, and I kinda doubt that), the test suite for py3k fails with 'FAILED (SKIP=17, errors=69, failures=13)' halting the build in my clean pbuilder env, the doc requirements list "sphinxcontrib-bibtex" which is not yet in debian (the reason I halted the upgrade myself sometime ago) so I'm not sure how the doc could have been built + all the time I wasted having to write this >, and that can't be easily > reverted before an upload to unstable? I dont know if I understand correctly: are you saying that, since he needed that package updated he could technical sub-optimal work, and then let the maintainer/somebody else fix what's left broken? because that's what's going to happen :( (python3-memcache anyone?) -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote: > Once again, the python policy about Maintainer/Uploaders has been ignored > > http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership > https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > > either policy changes or this has to stop at some point. > OTOH, this is experimental. It's not like this upload has any effect on anyone except to let Thomas work on packages that depend on it. Are there any specific changes you object to, and that can't be easily reverted before an upload to unstable? Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Sandro Tosi, 2015-09-29] > Once again, the python policy about Maintainer/Uploaders has been ignored > > http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership > https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > > either policy changes or this has to stop at some point. it still applies and I will start removing people from DPMT / PAPT who do not follow it. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Once again, the python policy about Maintainer/Uploaders has been ignored http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin either policy changes or this has to stop at some point. On Tue, Sep 29, 2015 at 12:19 PM, Debian FTP Masters wrote: > > > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Wed, 02 Sep 2015 13:17:15 + > Source: python-networkx > Binary: python-networkx python3-networkx python-networkx-doc > Architecture: source all > Version: 1.10-1 > Distribution: experimental > Urgency: medium > Maintainer: Sandro Tosi > Changed-By: Thomas Goirand > Description: > python-networkx - tool to create, manipulate and study complex networks > python-networkx-doc - tool to create, manipulate and study complex networks > - documenta > python3-networkx - tool to create, manipulate and study complex networks > (Python3) > Closes: 800431 > Changes: > python-networkx (1.10-1) experimental; urgency=medium > . >[ Sandro Tosi ] >* New upstream release (Closes: #800431). > . >[ Thomas Goirand ] >* Move to Build-Depends: what was in Build-Depends-Indep: but which is > needed > for the clean target. >* Dropped version of packages for those already provided in Jessie. >* Removed now useless python-3.4.patch patch from Chuck Short. >* Removed do-not-use-sphinx_rtd_theme.patch patch. Build-Depends on the > python-sphinx-rtd-theme package instead. >* Exclude tests which are doing internet access and failing. >* Do not rename non-existing README file. > Checksums-Sha1: > 43b217e9bfc7a180822f6bb72c507670fc4161b6 2550 python-networkx_1.10-1.dsc > 99292e464c25be5e96de295752880bf5e5f1848a 1189291 > python-networkx_1.10.orig.tar.gz > 1ec58c43a77675987a4c087f4034de393a8c31e6 187972 > python-networkx_1.10-1.debian.tar.xz > 858a5824f6ff6e20182d0b572319933485498c48 4483016 > python-networkx-doc_1.10-1_all.deb > ac050975613a620d1acb5b2a6e12f1d69dec34c6 820962 > python-networkx_1.10-1_all.deb > f6feb64baa117e593b1ad7a90f782fbc361b1bf8 621436 > python3-networkx_1.10-1_all.deb > Checksums-Sha256: > c25abfa8a95bcad43df30823b89e3d676674d00ec9d60c2c0e24165ac43ea710 2550 > python-networkx_1.10-1.dsc > ced4095ab83b7451cec1172183eff419ed32e21397ea4e1971d92a5808ed6fb8 1189291 > python-networkx_1.10.orig.tar.gz > b0ce586bcb110d276e6195c6dc9448f1aa7c30e1172d79053abf7e296f68030f 187972 > python-networkx_1.10-1.debian.tar.xz > f1f064fc93d9532743536474cdf4fce24e46599f74c79256461b4c4e17a19bda 4483016 > python-networkx-doc_1.10-1_all.deb > 280b30027e3d3f36e83d1bee434a456db80553e697e4ff21a399b136d2a7568e 820962 > python-networkx_1.10-1_all.deb > 6c615e4a23a98d62215bb49ba2746ce7111ba3fd53e2ef06f0f2a1b876f3ab54 621436 > python3-networkx_1.10-1_all.deb > Files: > 478146aafb466aa4480002d8e0283e56 2550 python optional > python-networkx_1.10-1.dsc > eb7a065e37250a4cc009919dacfe7a9d 1189291 python optional > python-networkx_1.10.orig.tar.gz > 7fc5a2a7210482fd793b5567a56e5471 187972 python optional > python-networkx_1.10-1.debian.tar.xz > c92c6f60db8e58f5964e640917503960 4483016 doc optional > python-networkx-doc_1.10-1_all.deb > 90fce4157d27999dde4bd61db1e46c7f 820962 python optional > python-networkx_1.10-1_all.deb > c1e4b687e06e67fea72228d29a17372b 621436 python optional > python3-networkx_1.10-1_all.deb > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJWCm7EAAoJENQWrRWsa0P+Bj8QAIlac+W7xs6l+1PmSCUOUmLI > qGH3HOHfDX+9uFCa1ILz41K2OnP8F54o9SAdHLY+ckdGXoSTNT//SlqalrfUwEfi > DXstqVfZGzgsJSh/a4cF4eutWRdEZeCcVGzhJvvZV5icIheRujEkD22BDPerw1fH > kIPzYnV9dKWGS7xf5gLEHivhu2GloazSMFDrCSF2jE+e1sAoQvpbuquxLfBS0xVg > 3kfDYIIXv3JV5WReETF/kN5us2eA34L4dAzehqe1+LLR9WEsjNTVCe7nuSV1/eyA > +R+wsPRlZNVlzuWz2ieshVL3BXD8EWf9jC2mYinIQhC+VxWLC0qNTNRE7JE4n+Gu > JJU2YvXLOIRHyld7EjYBrYqeZkz+buQ2Q036R5TQN4PH3H1jZKUrKhUdnBNgAf3Y > YqoactuiZyCvRjMSnsFzsr6hwjpvpHVgJkUDgfFTiJtVQDO/371VzJwtoPrXV4yI > obOD4MaW9n3afxF5NRRDZa2Nq8RRPAlNFu+u7sLrIvlUVe5ERSb7GnGWWAeNAF02 > okm8s9HVNZbs6BUoa8hz37OfyPc5AOW3XpOn1libP2JVW6+0Ah6/mU9fq56dOP5o > nVbMSC74MMy6xLmi3jBVk4ChQg2MwaXQzik55U6JW5MK3P9s6Sq0A67Zs+fuyE3M > GYO+p3rg2WMFx0SdeWjH > =ir36 > -END PGP SIGNATURE- > > > Thank you for your contribution to Debian. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Bug#800437: ITP: python-sievelib -- Client-side Sieve and Managesieve library
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-sievelib Version : 0.8 Upstream Author : Antoine Nguyen * URL : https://pypi.python.org/pypi/sievelib * License : Expat Programming Lang: Python Description : Client-side Sieve and Managesieve library Client-side Sieve and Managesieve library written in Python. . Sieve: Currently, the provided parser supports most of the functionalities described in RFC 5228. The only exception concerns section 2.4.2.4. Encoding Characters using "encoded-character" which is not supported. The following Sieve extensions are also supported: * Date and Index (RFC 5260) * Vacation (RFC 5230) . ManageSieve: All mandatory commands are supported. The RENAME extension is supported, with a simulated behaviour for server that do not support it. For the AUTHENTICATE command, supported mechanisms are DIGEST-MD5, PLAIN and LOGIN. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJWCmSZAAoJEGlMre9Rx7W2zxgQAJFiF8aI2HleVK/v4bBgXYW/ +piXia+uP5o1k0H2fLrI/HNumSQGUryQTz1iYMRb3z3OtRv/qGTnPNTchx2qpLBw chQJHAs8Gv/SRILFy8J+vs0P66QCORYevbN846ZjPO06/QkowVIywnm3BXgxkr7r eTShIgNG3S5tv1dosOXgzifqEowIHIlP6Z9iI6FfwhhGfsE+cs4j8znwOHfWcVEG EMqDb79fKlk19IAHAtyOL4cW7k3hBkoWQqyGu+1kZmJw18Imi3bUasP/MmCwIPAm ZoXyeQpvkGo59VkRpE0swYZNrjztSbx54f0XMgT8g5SAbUXBMTc5PYuA3pp2ZBYh Zvku0joyzVZKGooX4yRZ8AHtCOMLG9Xj2aFi7/sP5U9+0MZI2I51TeyBoC5lIb1L vFhUVA82dNTGC7xSqxOQrsggSsJdWzc6dds1E2WWCHVqZimLTKyqNTSaJeSaFNKa ZDG+BvNMJXaa9cnZI9kr5jVNqK6GuFi79Tafx25y+JToE38xMDFallpcGoOOrD3Q xMVAiMYfITTXTu0Bv8PITkM8OGEgWfvZUxlJpPQWiwVt5zyPXCDqY4MuxgT0Yebk I5X3ukw/Ek318vU0ntBkS05PIwO+5Tkf/69Y4j7h87sD67XfplNZELrRXg7FcEud VpxwsooeCPOtmX7VE/Xh =OsAc -END PGP SIGNATURE-