Hi |_eo
On Mon, Jan 23, 2017 at 01:42:52PM +0100, Leonardo Arena wrote:
> sorry but patching fails:> > >>> vice: fix__u_char.patch> patching file src/opencbm.h> Hunk #1 FAILED at 131 (different line endings).> 1 out of 1 hunk FAILED -- saving rejects to file src/opencbm.h.rej> > Can you send an updated patch? Also please note that APKBUILD checksums> are not updated.
I'm not 100% sure, but I think the problem lies on your end. According
to this stackoverflow article:
http://stackoverflow.com/questions/6289001/git-am-format-patch-control-format-of-line-endings/6677017#6677017
you should use:
git am --keep-cr
The whole problem is caused by opencbm.h using DOS line endings.
Please let me know if I am wrong. I'll then research the problem
further.
Best,
Jean-Louis
[alpine-aports] [PATCH] testing/lablgtk: new aport
---
Since ocaml can use the library either at run-time (interpreter) like a
python-module or to do native compile: I disabled the -dev split. Please review.
testing/lablgtk/APKBUILD | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 testing/lablgtk/APKBUILD
diff --git a/testing/lablgtk/APKBUILD b/testing/lablgtk/APKBUILD
new file mode 100644
index 0000000000..81dce38d9e
--- /dev/null+++ b/testing/lablgtk/APKBUILD
@@ -0,0 +1,44 @@
+# Contributor: Jean-Louis Fuchs <ganwell@fangorn.ch>+# Maintainer: Jean-Louis Fuchs <ganwell@fangorn.ch>+pkgname=lablgtk+pkgver=2.18.5+pkgrel=0+pkgdesc="LablGtk - an OCaml interface to GTK+ 2.x"+url="http://lablgtk.forge.ocamlcore.org/"+arch="all"+license="GPL"+# Most files are used for run-time and/or native-compile, so we don't do+# a dev split+depends="ocaml-findlib camlp4 ocaml gtk+-dev gtkspell-dev librsvg-dev+ gtksourceview2-dev"+makedepends="$depends"+install=""+subpackages="$pkgname-doc"+source="https://forge.ocamlcore.org/frs/download.php/1627/lablgtk-$pkgver.tar.gz"+builddir="$srcdir/lablgtk-$pkgver"++build() {+ cd "$builddir"+ ./configure --prefix=/usr || return 1+ make world || return 1+ make opt || return 1+ make doc || return 1+}+++doc() {+ pkgdesc="$pkgdesc (documentation)"+ _docdir="$subpkgdir"/usr/share/doc/$pkgname/+ mkdir -p "$_docdir"+ cp -r "$builddir"/doc/html/* "$_docdir"+}++package() {+ cd "$builddir"+ make DESTDIR="$pkgdir" install || return 1+ rm -f "$pkgdir"/usr/lib/ocaml/ld.conf+}++md5sums="43eb7062439f7ddd0d8ad96c3e3b87dd lablgtk-2.18.5.tar.gz"+sha256sums="2bf251db21c077fdd26c035ea03edd8fe609187f908e520e87a8ffdd9c36d233 lablgtk-2.18.5.tar.gz"+sha512sums="7b6ba1a4dfa82cc3bbc502082ff4fccc23cc06ee4f30d01a2e423f3f99e945a4befe450d230b5aa19c5b810e9f46f2838655099d49da2db7c8a2e52eac213024 lablgtk-2.18.5.tar.gz"
--
2.11.0
---
Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org
Help: alpine-aports+help@lists.alpinelinux.org
---
[alpine-aports] [PATCH v3] testing/vice: new aport
Hi,
On mar, 2017-01-24 at 16:15 +0100, Jean-Louis Fuchs wrote:
> ---> Since ocaml can use the library either at run-time (interpreter) like> a> python-module or to do native compile: I disabled the -dev split.> Please review.>
The dev stuff is ~5 MB, half of the package size (10MB).
I'm not familiar with ocaml. What would be the inconvenience in having
a separate -dev pkg? Would a user just want to use it at run-time only
or it's an unlikely scenario?
From Alpine packaging perspective only, 5 MB less in the system are
definitely worthy a pkg separation.
Thanks!
-|_eo
Re: [alpine-aports] [PATCH] testing/lablgtk: new aport
Hi |_eo
On Wed, Jan 25, 2017 at 01:46:02PM +0100, Leonardo Arena wrote:
I'm not familiar with ocaml, except for building unison.
> The dev stuff is ~5 MB, half of the package size (10MB).> I'm not familiar with ocaml. What would be the inconvenience in having> a separate -dev pkg?
If you do a native install you need lablgtk and lablgtk-dev. I thought
it might lead to confusion. I think we have these options:
1. Have the dev split and develeopers just have to remember installing
both packages if they want to do a native-compile.
2. Add lablgtk to depends_dev, so if you intend to do a native-compile
you will automatically get lablgtk.
3. My current solution.
I first wanted to go for 2. And then thought it might be considered a
hack.
> Would a user just want to use it at run-time only> or it's an unlikely scenario?
I guess a user never wants run-time only, since the distribution
usually does a native-compile. For example the native-compile package
of unison doesn't need lablgtk at run-time since its all linked into
unison.
But a ocaml developer probably wants run-time only, because he is
using the interpreter during development.
> From Alpine packaging perspective only, 5 MB less in the system are> definitely worthy a pkg separation.
So I guess we have to go for 1. or 2. let me know if 2. is ok.
Best,
Jean-Louis
Re: [alpine-aports] [PATCH] testing/lablgtk: new aport
On mer, 2017-01-25 at 14:25 +0100, Jean-Louis Fuchs wrote:
> Hi |_eo> > On Wed, Jan 25, 2017 at 01:46:02PM +0100, Leonardo Arena wrote:> > I'm not familiar with ocaml, except for building unison.> > > > > The dev stuff is ~5 MB, half of the package size (10MB).> > I'm not familiar with ocaml. What would be the inconvenience in> > having> > a separate -dev pkg?> If you do a native install you need lablgtk and lablgtk-dev. I> thought> it might lead to confusion. I think we have these options:> > 1. Have the dev split and develeopers just have to remember> installing> both packages if they want to do a native-compile.> > 2. Add lablgtk to depends_dev, so if you intend to do a native-> compile> you will automatically get lablgtk.> > 3. My current solution.> > I first wanted to go for 2. And then thought it might be considered a> hack.> > > > > Would a user just want to use it at run-time only> > or it's an unlikely scenario?> I guess a user never wants run-time only, since the distribution> usually does a native-compile. For example the native-compile package> of unison doesn't need lablgtk at run-time since its all linked into> unison.> > But a ocaml developer probably wants run-time only, because he is> using the interpreter during development.> > > > > From Alpine packaging perspective only, 5 MB less in the system are> > definitely worthy a pkg separation.> So I guess we have to go for 1. or 2. let me know if 2. is ok.>
Solution 2 sounds good to me.
I'm merged this patch and unison with this modification.
Thanks!
|_eo