| Message ID | 1382742930-11510-1-git-send-email-wzab01@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
Hi Wojciech, A few minor nits and one major issue. On 26/10/13 01:15, Wojciech M. Zabolotny wrote: > I have considered remarks provided by Ryan Barnett and Thomas De Schampheleire. > I hope that now the package definition is correct. Comments like this should not appear in the git history. You can do that by putting them below the Signed-off-by line, separated with --- on a line on its own. The part below the --- line is removed when the patch is committed with git am. Also, when sending an update, it is customary to add v2 to the subject so people can see which version is the latest one. You can do that by calling git send-email -v2 # Since git 1.8.x or git send-email --subject-prefix='PATCH v2' > > Signed-off-by: Wojciech M. Zabolotny <wzab01@gmail.com> > --- > package/Config.in | 1 + > package/python-pyusb/Config.in | 10 ++++++++++ > package/python-pyusb/python-pyusb.mk | 37 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 48 insertions(+) > create mode 100644 package/python-pyusb/Config.in > create mode 100644 package/python-pyusb/python-pyusb.mk > > diff --git a/package/Config.in b/package/Config.in > index 0e6f86c..40dba0c 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -400,6 +400,7 @@ source "package/python-protobuf/Config.in" > source "package/python-pygame/Config.in" > source "package/python-pyparsing/Config.in" > source "package/python-pyro/Config.in" > +source "package/python-pyusb/Config.in" > source "package/python-pyzmq/Config.in" > source "package/python-serial/Config.in" > source "package/python-setuptools/Config.in" > diff --git a/package/python-pyusb/Config.in b/package/python-pyusb/Config.in > new file mode 100644 > index 0000000..3a1242a > --- /dev/null > +++ b/package/python-pyusb/Config.in > @@ -0,0 +1,10 @@ > +config BR2_PACKAGE_PYTHON_PYUSB > + bool "python-pyusb" > + depends on BR2_PACKAGE_PYTHON > + select BR2_PACKAGE_LIBUSB libusb depends on threads so you should have depends on BR2_TOOLCHAIN_HAS_THREADS # libusb and comment "python-pyusb needs a toolchain w/ threads" depends on BR2_PACKAGE_PYTHON depends on !BR2_TOOLCHAIN_HAS_THREADS > + help > + The PyUSB module provides for Python easy access to the host > + machine's Universal Serial Bus (USB) system. > + Empty lines should be really empty, not contain spaces. > + http://sourceforge.net/apps/trac/pyusb/ > + Spurious empty line. > diff --git a/package/python-pyusb/python-pyusb.mk b/package/python-pyusb/python-pyusb.mk > new file mode 100644 > index 0000000..80609af > --- /dev/null > +++ b/package/python-pyusb/python-pyusb.mk > @@ -0,0 +1,37 @@ > +################################################################################ > +# > +# python-pyusb > +# > +################################################################################ > + > +PYTHON_PYUSB_VERSION = 0546cad8980783c39f96db717005a550059b730f > +PYTHON_PYUSB_SITE = http://github.com/walac/pyusb/tarball/$(PYTHON_PYUSB_VERSION) > +PYTHON_PYUSB_LICENSE = BSD-3c > +PYTHON_PYUSB_LICENSE_FILES = LICENSE > + > +PYTHON_PYUSB_DEPENDENCIES = python libusb libusb is only a runtime dependency, so it doesn't need to be added to the dependencies list. Otherwise, looks good :-) Regards, Arnout > + > +# Copied from python-pyparsing, based on python-pygame > +define PYTHON_PYUSB_BUILD_CMDS > + (cd $(@D); \ > + CC="$(TARGET_CC)" \ > + CFLAGS="$(TARGET_CFLAGS)" \ > + LDSHARED="$(TARGET_CROSS)gcc -shared" \ > + CROSS_COMPILING=yes \ > + _python_sysroot=$(STAGING_DIR) \ > + _python_srcdir=$(BUILD_DIR)/python$(PYTHON_VERSION) \ > + _python_prefix=/usr \ > + _python_exec_prefix=/usr \ > + $(HOST_DIR)/usr/bin/python setup.py build \ > + ) > +endef > + > +# Copied from python-pyparsing, based on python-pygame > +define PYTHON_PYUSB_INSTALL_TARGET_CMDS > + (cd $(@D); \ > + $(HOST_DIR)/usr/bin/python setup.py install \ > + --prefix=$(TARGET_DIR)/usr \ > + ) > +endef > + > +$(eval $(generic-package)) >
On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > Also, when sending an update, it is customary to add v2 to the subject so > people can see which version is the latest one. You can do that by calling > git send-email -v2 # Since git 1.8.x > or > git send-email --subject-prefix='PATCH v2' > It seems, that the above should be applied to git format-patch, not git send-email?
On 26/10/13 09:33, Wojciech Zabolotny wrote: > On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > >> Also, when sending an update, it is customary to add v2 to the subject so >> people can see which version is the latest one. You can do that by calling >> git send-email -v2 # Since git 1.8.x >> or >> git send-email --subject-prefix='PATCH v2' >> > > It seems, that the above should be applied to git format-patch, not > git send-email? You're right, but git send-email takes (almost) all of the options of git format-patch if you let it generate patches directly (e.g. with 'git send-email -1). Normally I don't bother with generating the patches separately and just mail them immediately - and I assumed that the rest of the world does the same :-). Regards, Arnout
Hi Arnout, On Mon, Oct 28, 2013 at 08:12:21AM +0100, Arnout Vandecappelle wrote: > On 26/10/13 09:33, Wojciech Zabolotny wrote: > >On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > >> Also, when sending an update, it is customary to add v2 to the subject > >> so > >>people can see which version is the latest one. You can do that by calling > >>git send-email -v2 # Since git 1.8.x > >>or > >>git send-email --subject-prefix='PATCH v2' > > > >It seems, that the above should be applied to git format-patch, not > >git send-email? > > You're right, but git send-email takes (almost) all of the options > of git format-patch if you let it generate patches directly (e.g. > with 'git send-email -1). Normally I don't bother with generating > the patches separately and just mail them immediately - and I > assumed that the rest of the world does the same :-). How do you add patch version changelog then? baruch
On 28/10/13 09:10, Baruch Siach wrote: > Hi Arnout, > > On Mon, Oct 28, 2013 at 08:12:21AM +0100, Arnout Vandecappelle wrote: >> On 26/10/13 09:33, Wojciech Zabolotny wrote: >>> On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: >>>> Also, when sending an update, it is customary to add v2 to the subject >>>> so >>>> people can see which version is the latest one. You can do that by calling >>>> git send-email -v2 # Since git 1.8.x >>>> or >>>> git send-email --subject-prefix='PATCH v2' >>> >>> It seems, that the above should be applied to git format-patch, not >>> git send-email? >> >> You're right, but git send-email takes (almost) all of the options >> of git format-patch if you let it generate patches directly (e.g. >> with 'git send-email -1). Normally I don't bother with generating >> the patches separately and just mail them immediately - and I >> assumed that the rest of the world does the same :-). > > How do you add patch version changelog then? Manually with git commit --amend. There is no way AFAIK to ensure consistency between the patch changelog and the -v option you pass to send-email/format-patch. There are a few tools like topgit and guilt that are supposed to make it easier to manage a patch with changelog, but I found them difficult to use. Regards, Arnout
Hi Arnout, On Mon, Oct 28, 2013 at 09:24:59AM +0100, Arnout Vandecappelle wrote: > On 28/10/13 09:10, Baruch Siach wrote: > >On Mon, Oct 28, 2013 at 08:12:21AM +0100, Arnout Vandecappelle wrote: > >>On 26/10/13 09:33, Wojciech Zabolotny wrote: > >>>On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > >>>> Also, when sending an update, it is customary to add v2 to the subject > >>>> so > >>>>people can see which version is the latest one. You can do that by calling > >>>>git send-email -v2 # Since git 1.8.x > >>>>or > >>>>git send-email --subject-prefix='PATCH v2' > >>> > >>>It seems, that the above should be applied to git format-patch, not > >>>git send-email? > >> > >> You're right, but git send-email takes (almost) all of the options > >>of git format-patch if you let it generate patches directly (e.g. > >>with 'git send-email -1). Normally I don't bother with generating > >>the patches separately and just mail them immediately - and I > >>assumed that the rest of the world does the same :-). > > >How do you add patch version changelog then? > > Manually with git commit --amend. But with 'commit --amend' you can only edit the log message itself, not the part below the '---' separator where patches changelog usually go. baruch > There is no way AFAIK to ensure consistency between the patch > changelog and the -v option you pass to send-email/format-patch. > There are a few tools like topgit and guilt that are supposed to > make it easier to manage a patch with changelog, but I found them > difficult to use.
On 28/10/13 09:40, Baruch Siach wrote: > Hi Arnout, > > On Mon, Oct 28, 2013 at 09:24:59AM +0100, Arnout Vandecappelle wrote: >> On 28/10/13 09:10, Baruch Siach wrote: >>> On Mon, Oct 28, 2013 at 08:12:21AM +0100, Arnout Vandecappelle wrote: >>>> On 26/10/13 09:33, Wojciech Zabolotny wrote: >>>>> On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: >>>>>> Also, when sending an update, it is customary to add v2 to the subject >>>>>> so >>>>>> people can see which version is the latest one. You can do that by calling >>>>>> git send-email -v2 # Since git 1.8.x >>>>>> or >>>>>> git send-email --subject-prefix='PATCH v2' >>>>> >>>>> It seems, that the above should be applied to git format-patch, not >>>>> git send-email? >>>> >>>> You're right, but git send-email takes (almost) all of the options >>>> of git format-patch if you let it generate patches directly (e.g. >>>> with 'git send-email -1). Normally I don't bother with generating >>>> the patches separately and just mail them immediately - and I >>>> assumed that the rest of the world does the same :-). >> >>> How do you add patch version changelog then? >> >> Manually with git commit --amend. > > But with 'commit --amend' you can only edit the log message itself, not the > part below the '---' separator where patches changelog usually go. Sure you can. The --- separator is only interpreted by git-am (well, actually the plumbing tool that is called by git-am). So you can update the things below the --- separator while doing git commit --amend or git rebase -i. Regards, Arnout
Hi Arnout, On Mon, Oct 28, 2013 at 09:47:17AM +0100, Arnout Vandecappelle wrote: > On 28/10/13 09:40, Baruch Siach wrote: > >On Mon, Oct 28, 2013 at 09:24:59AM +0100, Arnout Vandecappelle wrote: > >>On 28/10/13 09:10, Baruch Siach wrote: > >>>On Mon, Oct 28, 2013 at 08:12:21AM +0100, Arnout Vandecappelle wrote: > >>>>On 26/10/13 09:33, Wojciech Zabolotny wrote: > >>>>>On Sat, Oct 26, 2013 at 1:41 AM, Arnout Vandecappelle <arnout@mind.be> wrote: > >>>>>> Also, when sending an update, it is customary to add v2 to the subject > >>>>>> so > >>>>>>people can see which version is the latest one. You can do that by calling > >>>>>>git send-email -v2 # Since git 1.8.x > >>>>>>or > >>>>>>git send-email --subject-prefix='PATCH v2' > >>>>> > >>>>>It seems, that the above should be applied to git format-patch, not > >>>>>git send-email? > >>>> > >>>> You're right, but git send-email takes (almost) all of the options > >>>>of git format-patch if you let it generate patches directly (e.g. > >>>>with 'git send-email -1). Normally I don't bother with generating > >>>>the patches separately and just mail them immediately - and I > >>>>assumed that the rest of the world does the same :-). > >> > >>>How do you add patch version changelog then? > >> > >> Manually with git commit --amend. > > > >But with 'commit --amend' you can only edit the log message itself, not the > >part below the '---' separator where patches changelog usually go. > > Sure you can. The --- separator is only interpreted by git-am > (well, actually the plumbing tool that is called by git-am). So you > can update the things below the --- separator while doing git commit > --amend or git rebase -i. Nice trick. Should save me a lot of time. Thanks. baruch
diff --git a/package/Config.in b/package/Config.in index 0e6f86c..40dba0c 100644 --- a/package/Config.in +++ b/package/Config.in @@ -400,6 +400,7 @@ source "package/python-protobuf/Config.in" source "package/python-pygame/Config.in" source "package/python-pyparsing/Config.in" source "package/python-pyro/Config.in" +source "package/python-pyusb/Config.in" source "package/python-pyzmq/Config.in" source "package/python-serial/Config.in" source "package/python-setuptools/Config.in" diff --git a/package/python-pyusb/Config.in b/package/python-pyusb/Config.in new file mode 100644 index 0000000..3a1242a --- /dev/null +++ b/package/python-pyusb/Config.in @@ -0,0 +1,10 @@ +config BR2_PACKAGE_PYTHON_PYUSB + bool "python-pyusb" + depends on BR2_PACKAGE_PYTHON + select BR2_PACKAGE_LIBUSB + help + The PyUSB module provides for Python easy access to the host + machine's Universal Serial Bus (USB) system. + + http://sourceforge.net/apps/trac/pyusb/ + diff --git a/package/python-pyusb/python-pyusb.mk b/package/python-pyusb/python-pyusb.mk new file mode 100644 index 0000000..80609af --- /dev/null +++ b/package/python-pyusb/python-pyusb.mk @@ -0,0 +1,37 @@ +################################################################################ +# +# python-pyusb +# +################################################################################ + +PYTHON_PYUSB_VERSION = 0546cad8980783c39f96db717005a550059b730f +PYTHON_PYUSB_SITE = http://github.com/walac/pyusb/tarball/$(PYTHON_PYUSB_VERSION) +PYTHON_PYUSB_LICENSE = BSD-3c +PYTHON_PYUSB_LICENSE_FILES = LICENSE + +PYTHON_PYUSB_DEPENDENCIES = python libusb + +# Copied from python-pyparsing, based on python-pygame +define PYTHON_PYUSB_BUILD_CMDS + (cd $(@D); \ + CC="$(TARGET_CC)" \ + CFLAGS="$(TARGET_CFLAGS)" \ + LDSHARED="$(TARGET_CROSS)gcc -shared" \ + CROSS_COMPILING=yes \ + _python_sysroot=$(STAGING_DIR) \ + _python_srcdir=$(BUILD_DIR)/python$(PYTHON_VERSION) \ + _python_prefix=/usr \ + _python_exec_prefix=/usr \ + $(HOST_DIR)/usr/bin/python setup.py build \ + ) +endef + +# Copied from python-pyparsing, based on python-pygame +define PYTHON_PYUSB_INSTALL_TARGET_CMDS + (cd $(@D); \ + $(HOST_DIR)/usr/bin/python setup.py install \ + --prefix=$(TARGET_DIR)/usr \ + ) +endef + +$(eval $(generic-package))
I have considered remarks provided by Ryan Barnett and Thomas De Schampheleire. I hope that now the package definition is correct. Signed-off-by: Wojciech M. Zabolotny <wzab01@gmail.com> --- package/Config.in | 1 + package/python-pyusb/Config.in | 10 ++++++++++ package/python-pyusb/python-pyusb.mk | 37 ++++++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+) create mode 100644 package/python-pyusb/Config.in create mode 100644 package/python-pyusb/python-pyusb.mk