| Message ID | 1469969150-3029-1-git-send-email-mr.zoltan.gyarmati@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
Hello, On Sun, 31 Jul 2016 14:45:50 +0200, Zoltan Gyarmati wrote: > Signed-off-by: Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com> > --- > package/Config.in | 1 + > package/shapelib/Config.in | 8 ++++++++ > package/shapelib/shapelib.hash | 3 +++ > package/shapelib/shapelib.mk | 25 +++++++++++++++++++++++++ > 4 files changed, 37 insertions(+) > create mode 100644 package/shapelib/Config.in > create mode 100644 package/shapelib/shapelib.hash > create mode 100644 package/shapelib/shapelib.mk Thanks, I've applied your patch, after doing the following changes: [Thomas: - adjust the license: it's MIT or LGPLv2, add web/license.html to the license files - rewrap Config.in help text - add entry to the DEVELOPERS file.] Best regards, Thomas
Hi Thomas, On Wed, Sep 21, 2016 at 03:57:29PM +0200, Thomas Petazzoni wrote: > Thanks, I've applied your patch, after doing the following changes: > > [Thomas: > - adjust the license: it's MIT or LGPLv2, add web/license.html to the > license files > - rewrap Config.in help text > - add entry to the DEVELOPERS file.] A DEVELOPERS file update on every new package makes cherry-picking harder. For that reason, I think, Peter stopped updating the CHANGES file in every patch. baruch
Hello, On Wed, 21 Sep 2016 19:47:53 +0300, Baruch Siach wrote: > On Wed, Sep 21, 2016 at 03:57:29PM +0200, Thomas Petazzoni wrote: > > Thanks, I've applied your patch, after doing the following changes: > > > > [Thomas: > > - adjust the license: it's MIT or LGPLv2, add web/license.html to the > > license files > > - rewrap Config.in help text > > - add entry to the DEVELOPERS file.] > > A DEVELOPERS file update on every new package makes cherry-picking harder. For > that reason, I think, Peter stopped updating the CHANGES file in every patch. Right. What should we do then? Update the DEVELOPERS file in a separate patch? But then we're going to have zillions of patches whose sole purpose of to update the DEVELOPERS file. But of course, that's better for cherry-picking. Opinions? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Wed, 21 Sep 2016 19:47:53 +0300, Baruch Siach wrote: >> On Wed, Sep 21, 2016 at 03:57:29PM +0200, Thomas Petazzoni wrote: >> > Thanks, I've applied your patch, after doing the following changes: >> > >> > [Thomas: >> > - adjust the license: it's MIT or LGPLv2, add web/license.html to the >> > license files >> > - rewrap Config.in help text >> > - add entry to the DEVELOPERS file.] >> >> A DEVELOPERS file update on every new package makes cherry-picking harder. For >> that reason, I think, Peter stopped updating the CHANGES file in every patch. > Right. What should we do then? Update the DEVELOPERS file in a separate > patch? But then we're going to have zillions of patches whose sole > purpose of to update the DEVELOPERS file. But of course, that's better > for cherry-picking. Either that or I update DEVELOPERS when I also update CHANGES, but not everyone might want to get listed / might want to get listed without being the author of the commit adding the package.
Hi Peter, On Wed, Sep 21, 2016 at 11:12:29PM +0200, Peter Korsgaard wrote: > >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > On Wed, 21 Sep 2016 19:47:53 +0300, Baruch Siach wrote: > >> A DEVELOPERS file update on every new package makes cherry-picking > >> harder. For that reason, I think, Peter stopped updating the CHANGES > >> file in every patch. > > > Right. What should we do then? Update the DEVELOPERS file in a separate > > patch? But then we're going to have zillions of patches whose sole > > purpose of to update the DEVELOPERS file. But of course, that's better > > for cherry-picking. > > Either that or I update DEVELOPERS when I also update CHANGES, but not > everyone might want to get listed / might want to get listed without > being the author of the commit adding the package. A DEVELOPERS entry is probably most useful when the package is first added, as it starts showing up in the autobuilder. Delaying the DEVELOPERS update reduces its usefulness. baruch
>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes: Hi, >> Either that or I update DEVELOPERS when I also update CHANGES, but not >> everyone might want to get listed / might want to get listed without >> being the author of the commit adding the package. > A DEVELOPERS entry is probably most useful when the package is first added, as > it starts showing up in the autobuilder. Delaying the DEVELOPERS update > reduces its usefulness. Correct. I don't think the additional trivial commits to adjust DEVELOPERS are really an issue, so lets just ask people to send a 2nd patch to update the file whenever new packages (or families of packages) are added.
Hello, On Thu, 22 Sep 2016 06:41:42 +0300, Baruch Siach wrote: > > Either that or I update DEVELOPERS when I also update CHANGES, but not > > everyone might want to get listed / might want to get listed without > > being the author of the commit adding the package. > > A DEVELOPERS entry is probably most useful when the package is first added, as > it starts showing up in the autobuilder. Delaying the DEVELOPERS update > reduces its usefulness. Exactly my thought: I want the DEVELOPERS file to be updated at the same time as a package is added, so that as soon there are autobuilder failures, they are directly reported to the person who contributed the package. That's one of the big points for having this DEVELOPERS file. Best regards, Thomas
Hello, On Thu, 22 Sep 2016 07:16:06 +0200, Peter Korsgaard wrote: > > A DEVELOPERS entry is probably most useful when the package is first added, as > > it starts showing up in the autobuilder. Delaying the DEVELOPERS update > > reduces its usefulness. > > Correct. I don't think the additional trivial commits to adjust > DEVELOPERS are really an issue, so lets just ask people to send a 2nd > patch to update the file whenever new packages (or families of packages) > are added. OK. In fact the manual already says it should be done in a separate patch, so I simply failed to follow my own instructions :) Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: >> Correct. I don't think the additional trivial commits to adjust >> DEVELOPERS are really an issue, so lets just ask people to send a 2nd >> patch to update the file whenever new packages (or families of packages) >> are added. > OK. In fact the manual already says it should be done in a separate > patch, so I simply failed to follow my own instructions :) Hah! ;)
diff --git a/package/Config.in b/package/Config.in index 645fa29..6186da1 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1333,6 +1333,7 @@ endif source "package/protobuf-c/Config.in" source "package/qhull/Config.in" source "package/qlibc/Config.in" + source "package/shapelib/Config.in" source "package/sphinxbase/Config.in" source "package/startup-notification/Config.in" source "package/tinycbor/Config.in" diff --git a/package/shapelib/Config.in b/package/shapelib/Config.in new file mode 100644 index 0000000..a34a94d --- /dev/null +++ b/package/shapelib/Config.in @@ -0,0 +1,8 @@ +config BR2_PACKAGE_SHAPELIB + bool "shapelib" + help + The Shapefile C Library provides the ability to write simple C programs + for reading, writing and updating (to a limited extent) ESRI Shapefiles, + and the associated attribute file (.dbf). + + http://shapelib.maptools.org/ diff --git a/package/shapelib/shapelib.hash b/package/shapelib/shapelib.hash new file mode 100644 index 0000000..6c8a86f --- /dev/null +++ b/package/shapelib/shapelib.hash @@ -0,0 +1,3 @@ +# Locally computed +sha256 23d474016158ab5077db2f599527631706ba5c0dc7c4178a6a1d685bb014f68f shapelib-1.3.0.tar.gz + diff --git a/package/shapelib/shapelib.mk b/package/shapelib/shapelib.mk new file mode 100644 index 0000000..5c928cb --- /dev/null +++ b/package/shapelib/shapelib.mk @@ -0,0 +1,25 @@ +################################################################################ +# +# shapelib +# +################################################################################ + +SHAPELIB_VERSION = 1.3.0 +SHAPELIB_SITE = http://download.osgeo.org/shapelib +SHAPELIB_LICENSE = LGPL +SHAPELIB_LICENSE_FILES = LICENSE.LGPL +SHAPELIB_INSTALL_STAGING = YES + +define SHAPELIB_BUILD_CMDS + $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) +endef + +define SHAPELIB_INSTALL_STAGING_CMDS + $(MAKE) -C $(@D) PREFIX=$(STAGING_DIR)/usr/ lib_install +endef + +define SHAPELIB_INSTALL_TARGET_CMDS + $(MAKE) -C $(@D) PREFIX=$(TARGET_DIR)/usr/ bin_install +endef + +$(eval $(generic-package))
Signed-off-by: Zoltan Gyarmati <mr.zoltan.gyarmati@gmail.com> --- package/Config.in | 1 + package/shapelib/Config.in | 8 ++++++++ package/shapelib/shapelib.hash | 3 +++ package/shapelib/shapelib.mk | 25 +++++++++++++++++++++++++ 4 files changed, 37 insertions(+) create mode 100644 package/shapelib/Config.in create mode 100644 package/shapelib/shapelib.hash create mode 100644 package/shapelib/shapelib.mk