Re: Recommending get-orig-source for packages ?
On Wed, Dec 4, 2013 at 3:43 PM, Andreas Tille wrote: > That's in devscripts git and will be included in the next devscripts > version. (see [1]) Awesome, thanks for your work on that. That said, the choice of debian/copyright as the location for files to be excluded seems awkward/weird. I would have chosen debian/watch myself. > Is it??? http://lists.debian.org/20131203194424.ga26...@gmail.com -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6fds-rmwcn1xaurvsyiddnfxbfoqzfnler9oyyzn6m...@mail.gmail.com
Re: Recommending get-orig-source for packages ?
* Andreas Tille , 2013-12-04, 08:43: uscan to grow features for removing files from upstream tarballs, in a declarative way preferably. That's in devscripts git and will be included in the next devscripts version. (see [1]) So now you'll have to audit both d/watch and d/copyright before you can run uscan. *sigh* -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204081249.ga9...@jwilk.net
Re: Recommending get-orig-source for packages ?
Hi, On Wed, Dec 04, 2013 at 09:12:49AM +0100, Jakub Wilk wrote: > * Andreas Tille , 2013-12-04, 08:43: > >>uscan to grow features for removing files from upstream > >>tarballs, in a declarative way preferably. > >That's in devscripts git and will be included in the next > >devscripts version. (see [1]) > > So now you'll have to audit both d/watch and d/copyright before you > can run uscan. *sigh* Well, there was a lenthy discussion, uscan bug, Wiki page trying to summarise everything. The people who contributed did not brought up your (and Paul's concern) and I guess Charles Plessy would have been in favour of using d/upstream. I do not think it is my fault if you did not raised you voice when it was time ... By the way: currently you also have to audit another file in addition to d/watch if you need to exclude some files. So the solution is not actually a step back - it is just more structured now. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204094106.gc22...@an3as.eu
Re: Recommending get-orig-source for packages ?
* Andreas Tille , 2013-12-04, 10:41: uscan to grow features for removing files from upstream tarballs, in a declarative way preferably. That's in devscripts git and will be included in the next devscripts version. (see [1]) So now you'll have to audit both d/watch and d/copyright before you can run uscan. *sigh* AFAICS they way get_main_source_dir() is currently implemented lets malicious upstream to plant files in their tarball that would cause arbitrary code execution... Well, there was a lenthy discussion, uscan bug, Wiki page trying to summarise everything. The people who contributed did not brought up your (and Paul's concern) and I guess Charles Plessy would have been in favour of using d/upstream. I do not think it is my fault if you did not raised you voice when it was time ... https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net By the way: currently you also have to audit another file in addition to d/watch if you need to exclude some files. Unless you knew in advance that there's nothing to exclude, which was most often the case, and you could guess it just by looking at version. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204103001.ga6...@jwilk.net
Re: Recommending get-orig-source for packages ?
Le Wed, Dec 04, 2013 at 11:30:01AM +0100, Jakub Wilk a écrit : > * Andreas Tille , 2013-12-04, 10:41: > > >Well, there was a lenthy discussion, uscan bug, Wiki page trying > >to summarise everything. The people who contributed did not > >brought up your (and Paul's concern) and I guess Charles Plessy > >would have been in favour of using d/upstream. I do not think it > >is my fault if you did not raised you voice when it was time ... > > https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net (actually https://lists.debian.org/20130116133513.ga4...@jwilk.net) Hi Jakub, Debian has what its developers implement. I am sure that if somebody steps up and does the actual work of implementing a better solution and migrating the existing information, Andreas will complain. If out of our thousands of developers, only one person did a work (and is not in situation of monopoly), then we should not veto the outcome on the basis that somebody else could have done it better. Cheers, -- 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: http://lists.debian.org/20131204105810.gc21...@falafel.plessy.net
Re: Recommending get-orig-source for packages ?
* Charles Plessy , 2013-12-04, 19:58: Well, there was a lenthy discussion, uscan bug, Wiki page trying to summarise everything. The people who contributed did not brought up your (and Paul's concern) and I guess Charles Plessy would have been in favour of using d/upstream. I do not think it is my fault if you did not raised you voice when it was time ... https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net (actually https://lists.debian.org/20130116133513.ga4...@jwilk.net) D'oh. Hi Jakub, Debian has what its developers implement. I am sure that if somebody steps up and does the actual work of implementing a better solution and migrating the existing information, Andreas will complain. s/complain/comply/ perhaps? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204111348.ga9...@jwilk.net
Re: Recommending get-orig-source for packages ?
On Tue, Dec 3, 2013 at 17:06:22 +0100, Olivier Berger wrote: > Piotr Ożarowski writes: > > > [Olivier Berger, 2013-12-03] > >> Hi. > >> > >> I haven't spotted anything recommending a get-orig-source target in > >> debian/rules in the team's docs. > >> > >> I think it could be an interesting recommendation, as since the practice > >> seems to be only versioning the contents of the debian/ subdir, it could > >> be interesting to document, through that target where to get the orig > >> tarball. > >> > >> I guess most of the time, this could be derived from the debian/watch. > > > > if there's working debian/watch file, there's no need to add > > get-orig-source (and to be honest, I prefer debian/rules without > > get-orig-source if debian/watch is available) > > What's your rationale, Piotr ? > It adds 0 value, and is one more thing that can go wrong. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204113217.gb9...@crater1.logilab.fr
Re: Recommending get-orig-source for packages ?
Le Wed, Dec 04, 2013 at 12:13:48PM +0100, Jakub Wilk a écrit : > * Charles Plessy , 2013-12-04, 19:58: > >>>Well, there was a lenthy discussion, uscan bug, Wiki page > >>>trying to summarise everything. The people who contributed > >>>did not brought up your (and Paul's concern) and I guess > >>>Charles Plessy would have been in favour of using d/upstream. > >>>I do not think it is my fault if you did not raised you voice > >>>when it was time ... > >>https://lists.debian.org/debian-policy/20130116133513.ga4...@jwilk.net > > > >(actually https://lists.debian.org/20130116133513.ga4...@jwilk.net) > > D'oh. > > >Hi Jakub, > > > >Debian has what its developers implement. I am sure that if > >somebody steps up and does the actual work of implementing a > >better solution and migrating the existing information, Andreas > >will complain. > > s/complain/comply/ perhaps? D'oh as well. Indeed, I meant "will not complain", sorry for the noise... -- Charles -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204114901.gd15...@falafel.plessy.net
Re: Recommending get-orig-source for packages ?
On Wed, Dec 04, 2013 at 08:49:02PM +0900, Charles Plessy wrote: > > >better solution and migrating the existing information, Andreas > > >will complain. > > > > s/complain/comply/ perhaps? > > D'oh as well. > > Indeed, I meant "will not complain", sorry for the noise... I think all readers had the proper "mind reading abilities" to understand you in the first place. ;-) I hereby confirm that I would have been more than happy if somebody else would have implementet the functionality before me or if somebody else will enhance it to something even better. Since all is machine readable some automatic migration would be quite easy to do. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204124710.gd22...@an3as.eu
Re: Recommending get-orig-source for packages ?
On Wed, Dec 04, 2013 at 11:30:01AM +0100, Jakub Wilk wrote: > > AFAICS they way get_main_source_dir() is currently implemented lets > malicious upstream to plant files in their tarball that would cause > arbitrary code execution... Would you mind proposing a proper fix and forward it to the according bug report to let other people tha readers of debian-python know. Kind regards and thanks for any helpful hint Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204124831.ge22...@an3as.eu
Re: Recommending get-orig-source for packages ?
On Dec 04, 2013, at 01:36 PM, Stuart Prescott wrote: >Having uscan call "debian/rules get-orig-source" is quite difficult to do in >a policy-compliant way (as already noted by Jakub) as the location for the >munged tarball is different. Having uscan call a debian/repack from d/watch >seems a little more sane only because there's no policy saying what d/repack >must do; having uscan do the repacking itself with something like Files- >Excluded from d/copyright is even nicer and devscripts in git can do this. If you have a good example of a d/repack recipe, please do add it to the LibraryStyleGuide wiki page. I just added an example d/watch for packages which provide a tarball via PyPI (probably the majority of packages this team touches). >Like so many things in Debian there is more than one way to do something that >is truly simple and for which there probably should only be one way. It would >be nice if we didn't have more than one way of doing something as simple as >fetching an upstream source -- it's harder for automation, it's harder for >QA, it's harder for new maintainers and it's harder for casual bug >squashers. Without undertaking any sort of survey of packages, my feeling is >that the project is centralising on d/watch + uscan instead of >get-orig-source. One of my goals for LibraryStyleGuide and other Python-team related wiki pages is to be opinionated about the "best" way to do things, given the multitude of options. We may not always agree on what that best way is, but I think we all do agree on promoting techniques that lower the barrier to packaging Python goodness. After all, packaging is the boring part, right? :) -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204100013.7a475381@anarchist
Python 3 as default
I try to keep an eye on what other distros are doing w.r.t. Python 3. Here are Fedora's plans: https://fedoraproject.org/wiki/Changes/Python_3_as_Default https://fedoraproject.org/wiki/User:Bkabrda/Py2to3GuidelineChanges Some of these things are not relevant to us (e.g. DNF vs. yum). Others are interesting from a Python-aficionado point of view (e.g. cloud-init and other upstreams). I'd like to start thinking about what it would mean for Python 3 to be the "default" Python in Debian. This is not "what should /usr/bin/python point to" - I think we're all largely in agreement that that shouldn't change, at least for the foreseeable future (re: PEP 394). Instead, I mean, what would it take for the basic Debian system to install Python 3 only by default, and have any system scripts that depend on Python be Python 3. Anyway, this is mostly just FYI for those who like to keep tabs on the competition. :) Maybe "Python 3 as default" would be a nice Jessie+1 release goal. -Barry signature.asc Description: PGP signature
Re: Python 3 as default
On Wed, Dec 4, 2013 at 6:25 PM, Barry Warsaw wrote: > I try to keep an eye on what other distros are doing w.r.t. Python 3. Here > are Fedora's plans: > > https://fedoraproject.org/wiki/Changes/Python_3_as_Default > https://fedoraproject.org/wiki/User:Bkabrda/Py2to3GuidelineChanges > > Some of these things are not relevant to us (e.g. DNF vs. yum). Others are > interesting from a Python-aficionado point of view (e.g. cloud-init and other > upstreams). > > I'd like to start thinking about what it would mean for Python 3 to be the > "default" Python in Debian. This is not "what should /usr/bin/python point > to" - I think we're all largely in agreement that that shouldn't change, at > least for the foreseeable future (re: PEP 394). > > Instead, I mean, what would it take for the basic Debian system to install > Python 3 only by default, and have any system scripts that depend on Python be > Python 3. > > Anyway, this is mostly just FYI for those who like to keep tabs on the > competition. :) > > Maybe "Python 3 as default" would be a nice Jessie+1 release goal. > > -Barry What is required for it to be an unofficial release goal for Jessie? It should be an easier task than the Ubuntu 12.04 goal, since that covers the default desktop, while for Debian it would just be the netinstall (without any task chosen). -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caa77j2bz9ccgcs5+gezwk4vh0tqwau3id4h5dj6c4qhswa2...@mail.gmail.com
Re: Python 3 as default
Hi Barry, On Wed, Dec 04, 2013 at 11:25:16AM -0500, Barry Warsaw wrote: > I try to keep an eye on what other distros are doing w.r.t. Python 3. Here > are Fedora's plans: > https://fedoraproject.org/wiki/Changes/Python_3_as_Default > https://fedoraproject.org/wiki/User:Bkabrda/Py2to3GuidelineChanges > Some of these things are not relevant to us (e.g. DNF vs. yum). Others are > interesting from a Python-aficionado point of view (e.g. cloud-init and other > upstreams). > I'd like to start thinking about what it would mean for Python 3 to be the > "default" Python in Debian. This is not "what should /usr/bin/python point > to" - I think we're all largely in agreement that that shouldn't change, at > least for the foreseeable future (re: PEP 394). > Instead, I mean, what would it take for the basic Debian system to install > Python 3 only by default, and have any system scripts that depend on Python be > Python 3. > Anyway, this is mostly just FYI for those who like to keep tabs on the > competition. :) > Maybe "Python 3 as default" would be a nice Jessie+1 release goal. Why should it be Jessie+1 instead of Jessie? The set of packages that need ported in order to switch the default is minimal, and AFAIK python3 ports are already available for all of them thanks to Ubuntu taking the lead here. In fact, the last time I checked there were only 2-3 packages that actually needed changed in order to swap python for python3 in the default install - lsb-release is one of them, and I don't remember offhand what the others were. In short, I see no reason why Debian would want to stick with python2 by default in Jessie. The barrier is much lower than in Ubuntu, because Debian makes much less use of python in the default install. Cheers, -- 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: Python 3 as default
> Instead, I mean, what would it take for the basic Debian system to install > Python 3 only by default, and have any system scripts that depend on Python > be Python 3. Nothing. I just did a default no-tasks selected debian wheezy system and no version of python was installed. Using a cowbuilder wheezy & sid chroot I decided to see what python the tasks from tasksel install. (e.g. apt-get -s install task-web-server | grep python) Tasks: task-desktop (with --no-install-recommends): no Python task-gnome-desktop: (wheezy Python 2.7) (sid both Python 2.7 & Python 3.3) task-kde-desktop: (wheezy no Python) (sid Python 2.7) task-lxde-desktop: Python 2.7 task-xfce-desktop: no Python. task-web-server: no Python task-print-server: no Python task-database-server: no Python task-dns-server: (wheezy no Python) (sid Python 2.7) task-file-server: Python 2.7 task-mail-server: no Python task-ssh-server: no Python task-laptop: no Python Looking at the lists of packages suggested by apt-get it seemed like only Gnome that wanted lots of python packages. Diane signature.asc Description: This is a digitally signed message part.
Re: Recommending get-orig-source for packages ?
Barry Warsaw writes: > On Dec 04, 2013, at 01:36 PM, Stuart Prescott wrote: > > >Having uscan call "debian/rules get-orig-source" is quite difficult to do in > >a policy-compliant way (as already noted by Jakub) as the location for the > >munged tarball is different. Having uscan call a debian/repack from d/watch > >seems a little more sane only because there's no policy saying what d/repack > >must do; having uscan do the repacking itself with something like Files- > >Excluded from d/copyright is even nicer and devscripts in git can do this. > > If you have a good example of a d/repack recipe, please do add it to the > LibraryStyleGuide wiki page. We already have https://wiki.debian.org/onlyjob/get-orig-source>, in particular https://wiki.debian.org/onlyjob/get-orig-source#Repackaging_orig.tar>. Are you expecting ‘debian/repack’ to be significantly different when repacking Python-language packages, as opposed to the general case of repacking an upstream source tarball? What differences would be great enough to warrant a Python-library-specific recipe? -- \ “It is the mark of an educated mind to be able to entertain a | `\ thought without accepting it.” —Aristotle | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7wiov3oiyp@benfinney.id.au
