Re: Keeping upstream commits separate from Debian packaging commits
On 12 October 2014 08:49, Thomas Goirand wrote: > Also, during the Debconf discussion, we decided we would use the > pristine-tar workflow, *not* using upstream VCS merge. A > "git-import-orig" normally goes into a single commit, which I don't > think would bother anyone (not on the list, or on IRC). I wasn't at Debconf, maybe this is why I'm a bit confused by what you wrote here. pristine-tar and upstream VCS merge are in no way mutually exclusive, but you seem to be implying that they are; did I misread what you wrote? pristine-tar just needs a commit to base the tar delta off of; this can be a tag created via git-import-orig, but it can just as easily be a tag pulled from upstream. (Using upstream tags *without* using pristine-tar would seem to be inadvisable, with the possible exception of upstreams who don't release tarballs, and/or sign all their release tags) > the DPMT. Anyone who doesn't respect what we are collectively agree on > should IMO take the blame for what happened on IRC and on the commit > list, and pointing fingers at whoever configured it is IMO wrong. I haven't seen anyone write "importing upstream VCS into the Alioth repo is forbidden" anywhere; if this is the intent, then perhaps it should be clearly spelled out somewhere. (Or perhaps it already is, and I just missed it? In which case, whoops) -- mithrandi, i Ainil en-Balandor, a faer Ambar -- 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/CAMcKhMQTGotYsddxC+ynb5oFn0QrP1ng+hkui9Lv6U=4yfs...@mail.gmail.com
Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
On 2014-10-12 14:49, Thomas Goirand wrote: > Let's say there's a few more other people which > were not accounted for and that were not at Debconf, those who prefers > having upstream source code in the VCS are still the majority. And some weren't at Debconf and prefer to work with upstream sources. > Also, during the Debconf discussion, we decided we would use the > pristine-tar workflow, *not* using upstream VCS merge. Isn't pristine-tar deprecated by its author? I read https://bugs.debian.org/737871 and http://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/ and was therefore reluctant to use it. Anyway, I don't remember to encounter any problems with pristine-tar myself. > Anyone who doesn't respect what we are collectively agree on > should IMO take the blame for what happened on IRC and on the commit > list, and pointing fingers at whoever configured it is IMO wrong. Blaming and pointing fingers is almost always wrong :~) -- 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/20141012103613.GA2011@fama
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
On 12 October 2014 12:36, W. Martin Borgert wrote: > Isn't pristine-tar deprecated by its author? I read > https://bugs.debian.org/737871 and That's interesting, I didn't know about that. I'm not really sure I understand how dgit replaces pristine-tar, unless you assume that every tarball you want to store is in the archive. (Perhaps that's a reasonable assumption?) And since we are not planning to use dgit in DPMT (as I understand it), I'm not sure what the obvious way for us to replace pristine-tar is. > http://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/ This doesn't load for me at the moment (database error). Okay, found it in Google's cache; unfortunately the post doesn't say much beyond "I'm going to stop using pristine-tar". -- mithrandi, i Ainil en-Balandor, a faer Ambar -- 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/camckhmsope0fbowpxjesp5nyg8rjhp9jbxmltmmqsafmomm...@mail.gmail.com
Bug#764931: ITP: django-assets -- integrate webassets into Django applications
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: django-assets Version : 0.10 Upstream Author : Michael Elsdörfer * URL : https://github.com/miracle2k/django-assets * License : BSD Programming Lang: Python Description : integrate webassets into Django applications django-assets will automatically merge and compress bundle’s source files the first time a template including them is rendered, and will automatically update the compressed file every time a source file changes. If debugging is enabled, each source file will be outputted individually instead. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUOm/FAAoJEGlMre9Rx7W2KzgP/AlHrviVvXuCJaYKMMXSB1Re EP9egk6NrIE1EoX+wvboMvgMIJKyIAJQQ1zQJEKr69TKe7lxOby1FV34X/J8yTFo ryot+2vL/eW+Z9AH19A2RM/IuKiyKkFNYCvO3uWwS5MxqUsrUwG4dK4hTdA6qNXN 7/5VoHWIA0tu4h393KBJZLA+V7bJv25LezwKM2pEAt30EV6m9BwBbNyCJvpYeEPt L78BwQvGfHvq+7E42Cw5VUVGtu4NCsFcKDzXrrkwuDR9848EAJUGT14nUM2p8Zq+ ZXeI9OQsbV9su8qIZYl2bUVGKvJut/cis25qj0slf9EBDoT7Zn4zgxOxMe+Eoka6 72/YrXVvX20zqWf5OQhPJYzxN70wTr4ITGccNB1+v10JurKcrjtT5F6JCh7dfpcM 6me6sCYnlPqFhSmEa91W1NDNriuoVSWLJCg8laq9i88VGC/w/QCSONNd45q/p2fY D2x9knlHectcWMaMOfDx1hxFkncj+mK4B9hf+tOyTnYgcjXeooKzHz50KcJ+R2xK JSI+/ksfdiVRFaaR5MopsYx6LTVyr9kiLMTqVNGVdky+sCq3dW4KuGaaRELP7e1w CylQwNXKqOAQ92Tm7ZIzfcWaE0g1CRhBgE1+1WP1YPa/tFbAanlyltyWx2//mMVn ZKtdcLTyLNEr8APw4sG1 =PXhb -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/20141012121048.7590.57020.reportbug@kashyyyk.local
Re: Keeping upstream commits separate from Debian packaging commits
On October 12, 2014 2:49:47 AM EDT, Thomas Goirand wrote: >On 10/10/2014 12:59 PM, Ben Finney wrote: >> Scott Kitterman writes: >> >>> Changing the number of commits is solving the wrong problem. The >>> problem that needs to be solved is including upstream commits. >That's >>> thoroughly uninteresting for a packaging team. >> >> Agreed. This is a direct result of rebasing Debian packaging history >> onto upstream VCS history, and keeping them all in the same repo as >one >> undifferentiated history, no? > >The IRC bot and the commit-by-email function, while being nice, aren't >going to be the decision making features. What's going to be is what is >the most convenient for doing the packaging work. > >> It's a good illustration of why I much prefer the workflow of a >separate >> VCS for the ‘debian/’ directory, merged with upstream source only at >> build time. The results of the merge are in a separate location and >are >> never checked into VCS, they're used only for the build. >> >> See ‘git-buildpackage(1)’ for the ‘--git-overlay’ option, which AFAIK >> does this. >> >> That way, the history of the Debian packaging VCS is entirely about >> what happened to Debian packaging; upstream VCS history is elsewhere. >> That seems to address the trouble entirely. > >There are perfectly valid points for using what you describe above. But >also, there's some other reasons why it's preferable to have upstream >source within the VCS packaging branches. > >During Debconf 14, we had this discussion. Only Paultag wanted this, >everyone else didn't. Let's say there's a few more other people which >were not accounted for and that were not at Debconf, those who prefers >having upstream source code in the VCS are still the majority. > >Please, let's move on and not discuss it again... > >Also, during the Debconf discussion, we decided we would use the >pristine-tar workflow, *not* using upstream VCS merge. A >"git-import-orig" normally goes into a single commit, which I don't >think would bother anyone (not on the list, or on IRC). While I don't >agree with this decision, I prefer to just import upstream VCS and do >packaging based on tags, but I will still respect it when packaging in >the DPMT. Anyone who doesn't respect what we are collectively agree on >should IMO take the blame for what happened on IRC and on the commit >list, and pointing fingers at whoever configured it is IMO wrong. It's my fault someone else configured their git repos so IRC and the ML get flooded? Nonsense. I don't know who caused it to happen, but that's definitely where I'm (correctly) pointing fingers. 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/a7633e1a-c4d2-4ae0-a3ab-4d6b9b2c5...@kitterman.com
Bug#764945: ITP: djangorestframework-nested-resource -- DRF view mixin for nested resources
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: djangorestframework-nested-resource Version : 1.2.0 Upstream Author : SimpleEnergy * URL : https://github.com/simpleenergy/django-rest-framework-nested-resource * License : BSD Programming Lang: Python Description : DRF view mixin for nested resources djangorestframework-nested-resource provides view mixin for Django REST framework which simplifies nested resources. The mixin allows one to define a parent model on the Serializer level of Django REST framework. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUOoQeAAoJEGlMre9Rx7W2j3kP/2BlkgBh6+Pkl87FQoPfx0gF QK2MGScc6TirfnSCu26f0Yow55bZgSm/Khym5geXcRaYY9CWaZ0eudCjgZCPUMKM nEERrPLjMuEQIBykc/mNZ+AlkwOazgPwKkOw4WsjuD9aTVXUKKLN8maoS6wQUgIV PRg43+d9xp+AmNGP3A2K4PG8+reXPTa+bUPMjgrMLnurw9BwpubErHe72tbj4sdP U0/Hkym5AsaBN4uieyRAgCTrvREPzKyrDeTBB9ntqSR3XD/NRJTK4bJ5K92gCy6l vuA+hismZFUOP1BjEKPFC1wfG3iNZCVStWS+6DoNum1iribd39vjWg3ERodwAt+T H0OYxEzqcCD/i83y1dCAOGNF+YiaG/RnHs7K9grXs63edZMlnwRjc/bqmwSjbUwV Oniic+Gw6DaEvK6BTQ2BCqgBgGSWvIBwzvBG2iLU3r8knSuxUcrSZqxbAvTI4XFg J0sVJfkTRZBQ7oHMk10yaeOi1AKNlvDIIxKqQXCgfnrwFmrOmaWbn4BF0+CeLm/S M1uHFOdM8pdRTjoJkh2JTCZQ2/JD9kKGQQO5XPmYMfIAQnHG6sUmTs1x7FhDdYwT epq2uPdI8X6xQB+8AFJ7no0uC5c/eUZrAdt2XA/xZUtyovNRYG4FoSChy+ZNn+FQ ap90U9z+WLWdjGuJVG5K =UonW -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/20141012133736.8255.5506.reportbug@kashyyyk.local
Bug#764969: ITP: djangorestframework-gis -- Geographic add-ons for Django REST Framework
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: djangorestframework-gis Version : 0.7 Upstream Author : Douglas Meehan * URL : https://github.com/djangonauts/django-rest-framework-gis * License : Expat Programming Lang: Python Description : Geographic add-ons for Django REST Framework djangorestframework-gis extends the Django REST Framework to also handle geographic data as used by GeoDjango during serialization and deserialization. It provides the following features: .. * GeometryField: This field handles GeoDjango geometry fields, providing custom to_native and from_native methods for GeoJSON input/output. * GeoModelSerializer: This serializer updates the field_mapping dictionary to include field mapping of GeoDjango geometry fields to the above GeometryField. * GeoFeatureModelSerializer: GeoFeatureModelSerializer is a subclass of GeoModelSerializer which will output data in a format that is GeoJSON compatible. * InBBOXFilter: Filters a queryset to only those instances within a certain bounding box. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUOq/sAAoJEGlMre9Rx7W2ioYQALYxDcXF3m+DJYgCgM+znoMX lp7YJgFRYA5QSpPzfsx06MK5GjAzTvk1sWjyFzw8me4KSBiqlVBwT91/1Rc3aJVe IWAYEyzbsdbnJ2JmX0MKjAWW9QahTyGppk+QRopiWMSS7RKWF7KBy1+9Z5bSYc62 TvZxa148ebtn3PEfBhVGun+eIapfZLetonCTAH2hIHdchTZju5YpQ7LMIG5GiNBE QLW8PpVIwAUBJMw17Cwt47bgQCUP67ooEOouaib1G2svdpqKHtiMLl356ou/7hvp GD36awYvMb5vPBcy53TaffUZj++0VNU/qYgGnK4AzvhYomeyU5SlWRLroyDya0Bx zXjRxE+Mlav5E4+Ulo3MotcR22BaCa0B47B7vo5wJsswPuvdl/Q3s0jpiOK605U/ zHN/RdiHIhUWU/KifebB0bY5AcxkhnUqL99oZn6JSy0meoFrO2xQpGClTSPoKSIX jiC10W1ykQMMStUi/oE/BYO+k5sd7A+CLN1Czh3nCcoJCU731BXQlXg87TwAQw/q XG4NidlC/oxFq/V2OGSynBy9fW0xq/iq1A+GH7nUpgucOVly4MIfRU2HKGZh5fXH t7ZXdRSjgM1pYwLoD8yvgiagGvRT7oWB20PiZS5cmq33ATcL/syr7o/sd4xsNfvQ uCl8Cgerkx5HSrkZ3eCU =prqz -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/20141012164431.24497.88567.reportbug@kashyyyk.local
Re: Keeping upstream commits separate from Debian packaging commits
On Oct 12, 2014, at 02:49 PM, Thomas Goirand wrote: >Also, during the Debconf discussion, we decided we would use the >pristine-tar workflow, *not* using upstream VCS merge. More specifically, as I remember the discussion, it was decided that if upstream uses tarball based releases (as most PyPI packages do), then DPMT git vcses would also use a pristine-tar workflow. When upstream does not release tarballs, I think we decided to encourage pristine-tar, but to leave it to individual package maintainers to do what makes the most sense. However, in these cases, a README.source is required to explain the untypical packaging workflow. It also makes sense in those cases to ensure that the communication channels aren't overloaded with upstream commits, which I think are almost always going to be uninteresting to team members. >A "git-import-orig" normally goes into a single commit, which I don't think >would bother anyone (not on the list, or on IRC). Agreed. >While I don't agree with this decision, I prefer to just import upstream VCS >and do packaging based on tags, but I will still respect it when packaging in >the DPMT. Thank you. I personally appreciate the accommodations to the majority team decision. One other comment about commit notifications; we'll probably want to suppress notifications for initial commits of converted packages. I learned that the hard way for the last package I converted. 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/20141012181137.34075...@anarchist.wooz.org
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
On Oct 12, 2014, at 01:27 PM, Tristan Seligmann wrote: >That's interesting, I didn't know about that. I'm not really sure I >understand how dgit replaces pristine-tar, unless you assume that >every tarball you want to store is in the archive. (Perhaps that's a >reasonable assumption?) And since we are not planning to use dgit in >DPMT (as I understand it), I'm not sure what the obvious way for us to >replace pristine-tar is. In practice, I haven't seen any problems with pristine-tar. And given that archive uploads still currently require a tarball, and PyPI releases are overwhelmingly tarball-based, I think it still makes sense for DPMT to continue to use pristine-tar workflows by default. 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/20141012181419.6f734...@anarchist.wooz.org
Re: Keeping upstream commits separate from Debian packaging commits
On Oct 12, 2014, at 11:15 AM, Tristan Seligmann wrote: >I wasn't at Debconf, maybe this is why I'm a bit confused by what you >wrote here. pristine-tar and upstream VCS merge are in no way mutually >exclusive, but you seem to be implying that they are Maybe not mutually exclusive, but what's the point? I certainly would not base the Debian packaging on anything but the upstream tarball, and most git workflows provide those as an unpacked upstream source branch. Does upstream vcs add value? I can perhaps see it might help when importing patches, but it's almost always (IME) to find other ways to generate the patch. For example, you can always clone upstream into a different directory, or pull the patch from the code hosting site. In any case, if upstream vcs is included in the team git repo, then I think it's incumbent on maintainers of those packages to document that in README.source (both how it's done and *why*) and to ensure that notifications of upstream commits are suppressed to team mailing list and IRC. 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/20141012181934.1b6bb...@anarchist.wooz.org
Request to join the team
Dear all, some of you may have noticed my e-mail about approaching the recent "Attempt to unlock mutex that was not locked"-issue that several (Python) applications encounter [1]. Anyways, after several years of using Debian --and always returning from straying toward derived distros-- I would like to start giving something back and start packaging myself. My current interest lies with RabbitVCS [2] and especially its client for the filemanager "nemo". Since there already exists some package for Linux Mint, I consider this task to be a useful exercise for focusing on the process of packaging. Furthermore, I am in touch with the upstream developers of RabbitVCS and would like to strengthen the cooperation with this project for the good of both Debian and the project itself. Vincent offered me to sponsor a nemo-rabbitvcs package. Please add me to Alioth group for write access to the svn so that I can go ahead and upload. Regards Torsten [1] https://lists.debian.org/debian-python/2014/10/msg4.html [2] http://www.rabbitvcs.org -- 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/543b0bd8.8010...@matbox.de
Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)
Le Sun, Oct 12, 2014 at 06:14:19PM -0400, Barry Warsaw a écrit : > On Oct 12, 2014, at 01:27 PM, Tristan Seligmann wrote: > > >That's interesting, I didn't know about that. I'm not really sure I > >understand how dgit replaces pristine-tar, unless you assume that > >every tarball you want to store is in the archive. (Perhaps that's a > >reasonable assumption?) And since we are not planning to use dgit in > >DPMT (as I understand it), I'm not sure what the obvious way for us to > >replace pristine-tar is. > > In practice, I haven't seen any problems with pristine-tar. And given that > archive uploads still currently require a tarball, and PyPI releases are > overwhelmingly tarball-based, I think it still makes sense for DPMT to > continue to use pristine-tar workflows by default. Hi Barry, in the Debian Med team, we had concrete evidence last May that the pristine-tar data bitrots with time in the way explained by Joey on debian-devel. Sorry to not have a high-quality summary to propose, but you can have a look at the following thread and do not hesitate to ask for more information on our list if you would like. http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-May/026728.html http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-June/027063.html Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20141012234118.ga3...@falafel.plessy.net
