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: Searching for sponsor and critique
❦ 6 août 2015 22:15 +0200, Lennart Weller lenn...@lennartweller.de : I believe that we are still using SVN but maybe the switch to git will be done during the next Debconf. Personnaly, I don't really care if a package is team-maintained or not. It is better if it is and it will allow you to find another sponsor in case your regular sponsor is unresponsive. So, please apply to DPMT for python-prompt-toolkit. Do you already have an Alioth login? If not, please create one. I found a lot of automatic SVN imports on the git side of Alioth so I assumed the whole project is preparing a move so I went with what I knew best and used gbp and git-pbuilder. I have an Alioth login and I use it for my other packages. But I do need to apply to DPMT. It is quite possible that everything will be deleted and reimported again. I didn't follow all the discussions. We can also do a first upload outside the team and then migrate in the team once things are settled. [6] https://git.ring0.de/debian/python-prompt-toolkit - d/changelog: remove the source package automatically created by stdeb - d/control: use python-prompt-toolkit as a source package name, as it would avoid any future collision (and it is also the name for the GitHub repository) - d/control: add the appropriate Vcs-* (which will be updated later, just to not forget them) - d/control: short description should not start with a capital - d/rules: remove the comment about automatic generation I fixed those. I didn't add Vcs yet as I hadn't uploaded it to Alioth. I just set them to my git hosting for now and will change them when the upload is done. Same with the Maintainer field. The clone URL was at the top hidden behind the cloud download icon. OK, the interface was too similar to GitHub but not enough on this point. ;-) Everything looks good except the LICENSE.txt which is not here. It is in fact called LICENSE upstream and it should be added to the manifest to be present in the tarball. A note to upstream would be nice. Add a comment to debian/copyright pointing to the appropriate URL to find the license. As it is present in debian/copyright, you don't have to add a special patch or anything like that. -- The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain signature.asc Description: PGP signature
Bug#794839: ITP: djoser -- REST implementation of Django authentication system.
Package: wnpp Severity: wishlist Owner: Michael Fladischer fl...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: djoser Version : 0.3.1 Upstream Author : SUNSCRAPERS i...@sunscrapers.com * URL : https://github.com/sunscrapers/djoser * License : Expat Programming Lang: Python Description : REST implementation of Django authentication system. REST implementation of Django authentication system. Djoser library provides a set of Django Rest Framework views to handle basic actions such as registration, login, logout, password reset and account activation. It works with custom user models. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJVxG9tAAoJEGlMre9Rx7W2zTEQAIq5XHT5J8cbmp1u6fURFAGb z3OviJ/MqmniVaDxQEh0uuyeQUjhKgqzaUnmP6FtZeR9A2yPuzC+seQw5TSXRcnk 9IAtUiGuiexBTX4MGX/2c0A2GV0Z60x2l/mQZ7XGXkquUXeo7GxkPIIu9GpZh/wv Zs8OB8kJTgui5JSKqO1YNbokWLZN5ApdtV+dx4DTtcsxc8gz75ZNMJaYigOWYKPi cYZ/tXzuFJuWz/oWwqrmhvBCswPmcFwykAkLAggG1XFU02fAalEAFkfGe/H1/l81 MT5A+Cj5yIC1Qad4jBbaLaXXOnvDQM7rKM/Xr+9OQ1zfDUesAzoHN2vBoHSYbiRZ ZXzMYUN8lYrRETWIxVgv7kQAwg0Ta9CkATGD4I1Rg7odAhL7sWsRLF9+61OKZ+bc vJZ5wr4PmglwL5rKcT2D4YzmNKTy+ech/jplHCuSXXFnd/+nc2QS7PoAjW92CqTJ C4WsRrR9wsHaeeJmxggYsCs8BjR9NHo1yiClmKiAaM/T5f3sWG4+kt+ls3sFr2N5 7TR386DGrmKhmyii5dIBcffXamaOuvCv6DPh3nhHmZO8Bl8+/8mp2o+F7+WRaoQP ysRLO1gbJR5ECcipScWLb8l4L5cdWsYGfJApsv579ygiybkhcUo7xybHXCAb+Kpy H2bCCfXysnpxerDTCXc/ =oL7b -END PGP SIGNATURE- -- 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/20150807084225.7789.5065.reportbug@kashyyyk
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 ba...@debian.org 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 cutpaste 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 possible, and dealing with other-tool
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 ba...@debian.org 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 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!
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 hint, hint. 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 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
Bug#794885: ITP: django-rest-swagger -- Swagger Documentation Generator for Django REST Framework
Package: wnpp
Severity: wishlist
Owner: Michael Fladischer fl...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: django-rest-swagger
Version : 0.3.3
Upstream Author : Marc Gibbons marc_gibb...@rogers.com
* URL : https://github.com/marcgibbons/django-rest-swagger
* License : BSD-2-clause
Programming Lang: Python
Description : Swagger Documentation Generator for Django REST Framework
This project is built on the Django REST Framework Docs and uses the Swagger
from Wordnik as an interface. This application introspectively generates
documentation based on your Django REST Framework API code. Comments are
generated in combination from code analysis and comment extraction. Here are
some of the features that are documented:
* API title - taken from the class name
* Methods allowed
* Serializers fields in use by a certain method
* Field default values, minimum, maximum, read-only and required attributes
* URL parameters (ie. /product/{id})
* Field help_text property is used to create the description from the
serializer or model.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCgAGBQJVxNdEAAoJEGlMre9Rx7W2DVkP/24/tfAqG9TSLx+xb8JxD8m5
uZwOWSgtcW/QbWkhwaZe6cNOydb5d1mSJ57wj14Q9YvyfS1frRBnj/xEEeKPJDQK
AmhZuNcSuMOTEiZ6wwI3Qfy0cydu3H5zWZw1SEoCfu3XOvlt4RWgGvDLI1MHgMat
uqHavkYpN87OcvkrMYah92TchTHzX8SiKJ+cGhkI7boPz6sLNqXdrvk5C4ktawti
zqxDU3e5f0ILhhjnM8D+UZC8xiTk9da3Qvx1g72q62S0XdsG7b3ni0lWxreywFAQ
a4M7Vo4lMRwu2PfIIYeJCgtWDLgo8TLiZ7XqYTTyWUYGRwpuNiX3lW+mYI0tVFov
fbRS2EULS7b9dBBW69oZh85lDZfUd1QvCYGv16jeKmupAJ9EL1srGZzlBugOGdmx
E1jTfaYe263dysnSBpIl+/iqB1TnPUY+Xugt2ikPjr2pgF60RzIc26CXoKL7WIVs
R9TAV5JP3ZKhRQncejTBJtSqMwT8ZFb58Ox/esf0vxOyP6wYrogCYUadiqzuMxum
OgiiLKEupgkpNA7an9NsneQSvTJtBDpt9xaaauZSj7CwlwZw1V8dxyBhaq0pfoJT
3qVlY4rMgfzas4+AaVZ9ijD2ZctVSIskoi52ZWrKzwPAu3RsIk+MctA1aWS483zC
U5Aviq26OFngj9Lu10Y8
=PPSe
-END PGP SIGNATURE-
--
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/20150807160527.9959.47901.reportbug@kashyyyk
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 Friday, August 07, 2015 11:30:11 AM Sandro Tosi wrote: On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw ba...@debian.org 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 cutpaste 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
Please upload python-llfuse from DPMT SVN
Hello,
Does anyone have time to sponsor an upload of python-llfuse from the
DPMT SVN repository to unstable?
I've updated the package to a new Debian revision that fixes the
following bugs:
python-llfuse (0.40+dfsg-2) unstable; urgency=medium
* Correctly handle symlink-to-directory transition of
/usr/share/doc/{python,python3}-llfuse-dbg when upgrading from jessie.
Closes: #788161.
* Add versioned Breaks and Conflicts to -dbg packages to avoid
upgrade problems due to moved file. Closes: #781652.
* Put debugging symbols for regular interpreter into -dbg
package again. Closes: #781719.
* Bumped Standards-Version to 3.9.6 (no changes needed).
* Added missing build-depends on cython3 and cython-dbg.
Closes: #794056.
-- Nikolaus Rath nikol...@rath.org Wed, 29 Jul 2015 20:49:49 -0700
The package builds cleanly in a sid chroot as of several days ago (right
now it doesn't build because cython has become uninstallable).
Related to that, it would be fantastic if someone could also give me
upload permissions for this package, so that I can do future uploads on
my own (I'm a DM).
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
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/87oaiiphvl@vostro.rath.org
