[RFC] please review ebuilds for neovim and deps

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] please review ebuilds for neovim and deps

Ben de Groot-2
At the suggestion of radhermit, I'm putting my neovim & deps ebuilds
up here for review, before I commit them to the official tree. Do you
see any possible improvements?

Right now the neovim ebuild does not install any global default nvimrc
like we do with vim. We should probably consider doing so. Also, I'm
looking for the best way to let neovim use the vim plugins we install
in $VIMRUNTIME (such as gentoo-syntax).

The ebuilds are available in my personal dev overlay, and I'm
attaching them to this mail.
--
Cheers,

Ben | yngwin
Gentoo developer

neovim-0.0.0_pre20150220.ebuild (1K) Download Attachment
libtermkey-0.17.ebuild (1K) Download Attachment
msgpack-0.6.0_pre20150220.ebuild (1K) Download Attachment
unibilium-1.1.1.ebuild (856 bytes) Download Attachment
lua-MessagePack-0.3.2.ebuild (870 bytes) Download Attachment
neovim-python-client-0.0.28.ebuild (922 bytes) Download Attachment
trollius-1.0.4.ebuild (652 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Michał Górny-5
Hi,

Don't you think it sucks to review a few ebuilds in one e-mail? :)

neovim:

> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
> inherit cmake-utils flag-o-matic
>
> DESCRIPTION="Vim's rebirth for the 21st century"
> HOMEPAGE="https://github.com/neovim/neovim"
> if [[ ${PV} == 9999 ]]; then
> inherit git-r3
> EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> KEYWORDS=""
> else
> inherit vcs-snapshot
> COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} -> ${P}.tar.gz"
I don't think relying on stability of generated tarballs is a good
idea. The same applies to almost all other ebuilds.

> KEYWORDS="~amd64 ~x86"
> fi
>
> LICENSE="Apache-2.0 vim"
> SLOT="0"
> IUSE="perl python"
>
> CDEPEND="dev-lang/luajit
> >=dev-libs/libtermkey-0.17
> >=dev-libs/unibilium-1.1.1
> >=dev-libs/libuv-1.2.0
> >=dev-libs/msgpack-0.6.0_pre20150220  
Accidentally found trailing whitespace here!

> dev-lua/LuaBitOp
> dev-lua/lpeg
> dev-lua/lua-MessagePack"
> DEPEND="${CDEPEND}
> virtual/libiconv
> virtual/libintl"
> RDEPEND="${CDEPEND}
> perl? ( dev-lang/perl )
> python? ( dev-python/neovim-python-client )"
>
> src_configure() {
> append-cflags "-Wno-error"
> append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
> local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
That looks like a very bad idea. Doesn't that disable all the Gentoo
fancy overrides needed for sane CC/CXX etc.?

> cmake-utils_src_configure
> }

And in the end it fails to build with some linker errors like:

CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
tui.c:(.text+0x40c): undefined reference to `unibi_get_str'

or for ncurses, if libtermkey was linked against ncurses. Long story
short, it's linking to -ltermkey statically without providing
-lunibilium before it... which (static linking) is a horrible thing
to do anyway.

libtermkey:

> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
> inherit eutils multilib
>
> DESCRIPTION="Library for easy processing of keyboard entry from terminal-based programs"
> HOMEPAGE="http://www.leonerd.org.uk/code/libtermkey/"
> SRC_URI="http://www.leonerd.org.uk/code/${PN}/${P}.tar.gz"
>
> LICENSE="MIT"
> SLOT="0"
> KEYWORDS="~amd64 ~x86"
> IUSE="demos"
>
> RDEPEND="|| ( dev-libs/unibilium
> sys-libs/ncurses[unicode] )"
No, no, no, no, no and no. This dependency is meaningless, and broken.

You're looking for either:

# ignore ncurses since neovim will pull in unibilium anyway,
# and then libtermkey will prefer it
RDEPEND="dev-libs/unibilium:="

or a USE flag to toggle the two. No auto-magic || () is doing.

> DEPEND="${RDEPEND}
> sys-devel/libtool

Using system-wide libtool is horrendously broken. This is something for
upstream to fix (like they should start using a sane build system)
but if you really want to commit it like this, already open a bug alike
https://bugs.gentoo.org/show_bug.cgi?id=515554.

The same applies to unibilium.

> virtual/pkgconfig
> demos? ( dev-libs/glib:2 )"
>
> src_prepare() {
> if ! use demos; then
> sed -e 's|all: $(LIBRARY) $(DEMOS)|all: $(LIBRARY)|' -i Makefile || die

sed -e '/^all:/s:$(DEMOS)::' ...

> fi
> }
>
> src_compile() {
> emake PREFIX="${EPREFIX}/usr" all

You need LIBDIR here too, otherwise the executable gets wrong rpath.

The same applies to unibilium. Also unibilium doesn't respect CC here.

> }
>
> src_install() {
> emake PREFIX="${EPREFIX}/usr" LIBDIR="${EPREFIX}/usr/$(get_libdir)" \
> DESTDIR="${D}" install
> prune_libtool_files
> }

neovim-python-client:

> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
> PYTHON_COMPAT=( python{2_7,3_3,3_4} pypy )
> inherit distutils-r1
>
> DESCRIPTION="Python client to connect to Neovim thru its msgpack-rpc API"
> HOMEPAGE="https://github.com/neovim/python-client"
> SRC_URI="https://github.com/neovim/python-client/archive/0.0.28.tar.gz -> ${P}.tar.gz"
Hardcoded PV. And obviously github generated tarball :).

>
> LICENSE="Apache-2.0"
> SLOT="0"
> KEYWORDS="~amd64 ~x86"
> IUSE=""
>
> DEPEND=">=dev-python/click-3.0
> >=dev-python/msgpack-0.4.0  
> !python_targets_pypy? ( dev-python/greenlet )
> !python_targets_python3_4? ( dev-python/trollius )"
Whaaaaaaaaaaaaaaaaat?! What are those negative deps supposed to mean?

I'm pretty sure you meant:

$(python_gen_cond_dep 'python*' 'dev-python/greenlet[${PYTHON_USEDEP}]')
$(python_gen_cond_dep python{2_7,3_2,3_3} 'pypy*' 'dev-python/trollius[${PYTHON_USEDEP}]')

> RDEPEND="${DEPEND}"
>
> S=${WORKDIR}/${P/neovim-/}


--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

hasufell
Michał Górny:

>> dev-lua/LuaBitOp
>> dev-lua/lpeg
>> dev-lua/lua-MessagePack"
>> DEPEND="${CDEPEND}
>> virtual/libiconv
>> virtual/libintl"
>> RDEPEND="${CDEPEND}
>> perl? ( dev-lang/perl )
>> python? ( dev-python/neovim-python-client )"
>>
>> src_configure() {
>> append-cflags "-Wno-error"
>> append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
>> local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
>
> That looks like a very bad idea. Doesn't that disable all the Gentoo
> fancy overrides needed for sane CC/CXX etc.?
>

Not necessarily. It depends on details of the build system. cmake eclass
is a huge hack which works often, but not always.

One should examine the build log.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Paweł Hajdan, Jr.
In reply to this post by Ben de Groot-2
On 2/20/15 12:10 PM, Ben de Groot wrote:
> At the suggestion of radhermit, I'm putting my neovim & deps ebuilds
> up here for review, before I commit them to the official tree. Do you
> see any possible improvements?

Overall the ebuilds look nice and clean. Some ideas:

- consider asking libtermkey upstream to provide a way to make demos
optional in a cleaner way than sed over the Makefile

- in neovim-python-client, 0.0.28.tar.gz is hardcoded in the ebuild;
consider using ${PV} instead

Paweł


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Ben de Groot-2
In reply to this post by Michał Górny-5
On 21 February 2015 at 16:18, Michał Górny <[hidden email]> wrote:
> Hi,
>
> Don't you think it sucks to review a few ebuilds in one e-mail? :)

No. :)

> neovim:
>
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI=5
>> inherit cmake-utils flag-o-matic
>>
>> DESCRIPTION="Vim's rebirth for the 21st century"
>> HOMEPAGE="https://github.com/neovim/neovim"
>> if [[ ${PV} == 9999 ]]; then
>>       inherit git-r3
>>       EGIT_REPO_URI="git://github.com/neovim/neovim.git"
>>       KEYWORDS=""
>> else
>>       inherit vcs-snapshot
>>       COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
>>       SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} -> ${P}.tar.gz"
>
> I don't think relying on stability of generated tarballs is a good
> idea. The same applies to almost all other ebuilds.

Do we often run into trouble with that? I know it's not perfect, but
it should be temporary, until we get regular releases.

>>       KEYWORDS="~amd64 ~x86"
>> fi
>>
>> LICENSE="Apache-2.0 vim"
>> SLOT="0"
>> IUSE="perl python"
>>
>> CDEPEND="dev-lang/luajit
>>       >=dev-libs/libtermkey-0.17
>>       >=dev-libs/unibilium-1.1.1
>>       >=dev-libs/libuv-1.2.0
>>       >=dev-libs/msgpack-0.6.0_pre20150220
>
> Accidentally found trailing whitespace here!

Not present in the actual ebuild.

>>       dev-lua/LuaBitOp
>>       dev-lua/lpeg
>>       dev-lua/lua-MessagePack"
>> DEPEND="${CDEPEND}
>>       virtual/libiconv
>>       virtual/libintl"
>> RDEPEND="${CDEPEND}
>>       perl? ( dev-lang/perl )
>>       python? ( dev-python/neovim-python-client )"
>>
>> src_configure() {
>>       append-cflags "-Wno-error"
>>       append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
>>       local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
>
> That looks like a very bad idea. Doesn't that disable all the Gentoo
> fancy overrides needed for sane CC/CXX etc.?

Any other way to do that then?

>>       cmake-utils_src_configure
>> }
>
> And in the end it fails to build with some linker errors like:
>
> CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
> tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
> CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
> tui.c:(.text+0x40c): undefined reference to `unibi_get_str'
>
> or for ncurses, if libtermkey was linked against ncurses. Long story
> short, it's linking to -ltermkey statically without providing
> -lunibilium before it... which (static linking) is a horrible thing
> to do anyway.

WFM, but yeah it's not ideal. I'll contact upstream about it.

> libtermkey:
>
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI=5
>> inherit eutils multilib
>>
>> DESCRIPTION="Library for easy processing of keyboard entry from terminal-based programs"
>> HOMEPAGE="http://www.leonerd.org.uk/code/libtermkey/"
>> SRC_URI="http://www.leonerd.org.uk/code/${PN}/${P}.tar.gz"
>>
>> LICENSE="MIT"
>> SLOT="0"
>> KEYWORDS="~amd64 ~x86"
>> IUSE="demos"
>>
>> RDEPEND="|| ( dev-libs/unibilium
>>               sys-libs/ncurses[unicode] )"
>
> No, no, no, no, no and no. This dependency is meaningless, and broken.
>
> You're looking for either:
>
> # ignore ncurses since neovim will pull in unibilium anyway,
> # and then libtermkey will prefer it
> RDEPEND="dev-libs/unibilium:="
>
> or a USE flag to toggle the two. No auto-magic || () is doing.

Since neovim upstream now moved completely from ncurses to unibilium,
I guess it makes sense to just do that here too.

>> DEPEND="${RDEPEND}
>>       sys-devel/libtool
>
> Using system-wide libtool is horrendously broken. This is something for
> upstream to fix (like they should start using a sane build system)
> but if you really want to commit it like this, already open a bug alike
> https://bugs.gentoo.org/show_bug.cgi?id=515554.

I'll report upstream. Anything else we can do in the meantime?

> The same applies to unibilium.
>
>>       virtual/pkgconfig
>>       demos? ( dev-libs/glib:2 )"
>>
>> src_prepare() {
>>       if ! use demos; then
>>               sed -e 's|all: $(LIBRARY) $(DEMOS)|all: $(LIBRARY)|' -i Makefile || die
>
> sed -e '/^all:/s:$(DEMOS)::' ...
>
>>       fi
>> }
>>
>> src_compile() {
>>       emake PREFIX="${EPREFIX}/usr" all
>
> You need LIBDIR here too, otherwise the executable gets wrong rpath.

ok

> The same applies to unibilium. Also unibilium doesn't respect CC here.
>
>> }
>>
>> src_install() {
>>       emake PREFIX="${EPREFIX}/usr" LIBDIR="${EPREFIX}/usr/$(get_libdir)" \
>>               DESTDIR="${D}" install
>>       prune_libtool_files
>> }
>
> neovim-python-client:
>
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI=5
>> PYTHON_COMPAT=( python{2_7,3_3,3_4} pypy )
>> inherit distutils-r1
>>
>> DESCRIPTION="Python client to connect to Neovim thru its msgpack-rpc API"
>> HOMEPAGE="https://github.com/neovim/python-client"
>> SRC_URI="https://github.com/neovim/python-client/archive/0.0.28.tar.gz -> ${P}.tar.gz"
>
> Hardcoded PV. And obviously github generated tarball :).

Oops! That was an oversight.

>>
>> LICENSE="Apache-2.0"
>> SLOT="0"
>> KEYWORDS="~amd64 ~x86"
>> IUSE=""
>>
>> DEPEND=">=dev-python/click-3.0
>>       >=dev-python/msgpack-0.4.0
>>       !python_targets_pypy? ( dev-python/greenlet )
>>       !python_targets_python3_4? ( dev-python/trollius )"
>
> Whaaaaaaaaaaaaaaaaat?! What are those negative deps supposed to mean?

We need pypy OR greenlet, and python-3.4 OR trollius. This was the
simplest way I saw to express that.

> I'm pretty sure you meant:
>
> $(python_gen_cond_dep 'python*' 'dev-python/greenlet[${PYTHON_USEDEP}]')
> $(python_gen_cond_dep python{2_7,3_2,3_3} 'pypy*' 'dev-python/trollius[${PYTHON_USEDEP}]')

Hmm, black magic?! Tasty!
After perusing the grimoire--I mean eclass--I get the idea. Thanks for the hint!

>> RDEPEND="${DEPEND}"
>>
>> S=${WORKDIR}/${P/neovim-/}
>
>
> --
> Best regards,
> Michał Górny

Thanks for reviewing!

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Tim Harder-5
On 2015-02-21 13:19, Ben de Groot wrote:

> > neovim:
> >
> >> # Copyright 1999-2015 Gentoo Foundation
> >> # Distributed under the terms of the GNU General Public License v2
> >> # $Header: $
> >>
> >> EAPI=5
> >> inherit cmake-utils flag-o-matic
> >>
> >> DESCRIPTION="Vim's rebirth for the 21st century"
> >> HOMEPAGE="https://github.com/neovim/neovim"
> >> if [[ ${PV} == 9999 ]]; then
> >>       inherit git-r3
> >>       EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> >>       KEYWORDS=""
> >> else
> >>       inherit vcs-snapshot
> >>       COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> >>       SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} -> ${P}.tar.gz"
> >
> > I don't think relying on stability of generated tarballs is a good
> > idea. The same applies to almost all other ebuilds.

> Do we often run into trouble with that? I know it's not perfect, but
> it should be temporary, until we get regular releases.

Personally I'd rather do manual snapshot releases for now. Many vim
packages end up being handled in the same fashion anyway (glance at [1]
for proof).

Tim

[1]: http://dev.gentoo.org/~radhermit/vim/

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Michał Górny-5
In reply to this post by Ben de Groot-2
Dnia 2015-02-22, o godz. 02:19:18
Ben de Groot <[hidden email]> napisał(a):

> > neovim:
> >
> >> # Copyright 1999-2015 Gentoo Foundation
> >> # Distributed under the terms of the GNU General Public License v2
> >> # $Header: $
> >>
> >> EAPI=5
> >> inherit cmake-utils flag-o-matic
> >>
> >> DESCRIPTION="Vim's rebirth for the 21st century"
> >> HOMEPAGE="https://github.com/neovim/neovim"
> >> if [[ ${PV} == 9999 ]]; then
> >>       inherit git-r3
> >>       EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> >>       KEYWORDS=""
> >> else
> >>       inherit vcs-snapshot
> >>       COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> >>       SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} -> ${P}.tar.gz"
> >
> > I don't think relying on stability of generated tarballs is a good
> > idea. The same applies to almost all other ebuilds.
>
> Do we often run into trouble with that? I know it's not perfect, but
> it should be temporary, until we get regular releases.
Depends if you belong to the 'I care only about mirrors' camp or the one
that wants SRC_URI to be always correct.

I actually hit the unlucky case when the tarball checksum changed
between ebuild upload and mirror fetching :).

> >>       dev-lua/LuaBitOp
> >>       dev-lua/lpeg
> >>       dev-lua/lua-MessagePack"
> >> DEPEND="${CDEPEND}
> >>       virtual/libiconv
> >>       virtual/libintl"
> >> RDEPEND="${CDEPEND}
> >>       perl? ( dev-lang/perl )
> >>       python? ( dev-python/neovim-python-client )"
> >>
> >> src_configure() {
> >>       append-cflags "-Wno-error"
> >>       append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
> >>       local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
> >
> > That looks like a very bad idea. Doesn't that disable all the Gentoo
> > fancy overrides needed for sane CC/CXX etc.?
>
> Any other way to do that then?
Leave it at default (=Gentoo)?

> >>       cmake-utils_src_configure
> >> }
> >
> > And in the end it fails to build with some linker errors like:
> >
> > CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
> > tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
> > CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
> > tui.c:(.text+0x40c): undefined reference to `unibi_get_str'
> >
> > or for ncurses, if libtermkey was linked against ncurses. Long story
> > short, it's linking to -ltermkey statically without providing
> > -lunibilium before it... which (static linking) is a horrible thing
> > to do anyway.
>
> WFM, but yeah it's not ideal. I'll contact upstream about it.
It may be a gold linker case.

> >> DEPEND="${RDEPEND}
> >>       sys-devel/libtool
> >
> > Using system-wide libtool is horrendously broken. This is something for
> > upstream to fix (like they should start using a sane build system)
> > but if you really want to commit it like this, already open a bug alike
> > https://bugs.gentoo.org/show_bug.cgi?id=515554.
>
> I'll report upstream. Anything else we can do in the meantime?

Well, you can ignore it for now. I was wondering about preparing
a quick tarball with configure.ac to pregenerate libtool for ebuilds
but none of the maintainers replied about needing it. Maybe I should
consider it a QA business :).

> >>
> >> LICENSE="Apache-2.0"
> >> SLOT="0"
> >> KEYWORDS="~amd64 ~x86"
> >> IUSE=""
> >>
> >> DEPEND=">=dev-python/click-3.0
> >>       >=dev-python/msgpack-0.4.0
> >>       !python_targets_pypy? ( dev-python/greenlet )
> >>       !python_targets_python3_4? ( dev-python/trollius )"
> >
> > Whaaaaaaaaaaaaaaaaat?! What are those negative deps supposed to mean?
>
> We need pypy OR greenlet, and python-3.4 OR trollius. This was the
> simplest way I saw to express that.
But if you want both pypy and cpython, you still need greenlet for
cpython. Same for trollius and old versions of python.

> > I'm pretty sure you meant:
> >
> > $(python_gen_cond_dep 'python*' 'dev-python/greenlet[${PYTHON_USEDEP}]')
> > $(python_gen_cond_dep python{2_7,3_2,3_3} 'pypy*' 'dev-python/trollius[${PYTHON_USEDEP}]')
>
> Hmm, black magic?! Tasty!
> After perusing the grimoire--I mean eclass--I get the idea. Thanks for the hint!


--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Michael Orlitzky
In reply to this post by Michał Górny-5
On 02/21/2015 03:18 AM, Michał Górny wrote:
>
>> DEPEND="${RDEPEND}
>> sys-devel/libtool
>
> Using system-wide libtool is horrendously broken. This is something for
> upstream to fix (like they should start using a sane build system)
> but if you really want to commit it like this, already open a bug alike
> https://bugs.gentoo.org/show_bug.cgi?id=515554.
>

Bug #515554 is only about /usr/bin/libtool, I think. I added a
sys-devel/libtool dependency in,

  https://bugs.gentoo.org/show_bug.cgi?id=401237

because Nagios needs libltdl to build. Is that still a problem?


Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Michał Górny-5
Dnia 2015-02-21, o godz. 14:43:05
Michael Orlitzky <[hidden email]> napisał(a):

> On 02/21/2015 03:18 AM, Michał Górny wrote:
> >
> >> DEPEND="${RDEPEND}
> >> sys-devel/libtool
> >
> > Using system-wide libtool is horrendously broken. This is something for
> > upstream to fix (like they should start using a sane build system)
> > but if you really want to commit it like this, already open a bug alike
> > https://bugs.gentoo.org/show_bug.cgi?id=515554.
> >
>
> Bug #515554 is only about /usr/bin/libtool, I think.
Yes.

> I added a
> sys-devel/libtool dependency in,
>
>   https://bugs.gentoo.org/show_bug.cgi?id=401237
>
> because Nagios needs libltdl to build. Is that still a problem?

Yes, it is. Because dev-libs/libltdl.

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Michael Orlitzky
On 02/21/2015 04:05 PM, Michał Górny wrote:
>>
>>   https://bugs.gentoo.org/show_bug.cgi?id=401237
>>
>> because Nagios needs libltdl to build. Is that still a problem?
>
> Yes, it is. Because dev-libs/libltdl.
>

Thanks, it looks like I investigated the bug on the same day that
package was committed. I was revbumping nagios-core today anyway, so
I'll fix this at the same time.


Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

William Hubbs
In reply to this post by Michał Górny-5
On Sat, Feb 21, 2015 at 09:18:08AM +0100, Michał Górny wrote:

> neovim:
>
> > # Copyright 1999-2015 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header: $
> >
> > EAPI=5
> > inherit cmake-utils flag-o-matic
> >
> > DESCRIPTION="Vim's rebirth for the 21st century"
> > HOMEPAGE="https://github.com/neovim/neovim"
> > if [[ ${PV} == 9999 ]]; then
> > inherit git-r3
> > EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> > KEYWORDS=""
> > else
> > inherit vcs-snapshot
> > COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> > SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} -> ${P}.tar.gz"
>
> I don't think relying on stability of generated tarballs is a good
> idea. The same applies to almost all other ebuilds.
If the tarball is based on an upstream tag, you should be fine, but this
does not work for a commit hash like what is being used here.

For more info on this, check out the man page for git archive. In
particular, how it handles timestamps inside the tarball.

In a nutshell, if you use git archive to create a tarball based on a
commit hash, the time stamps of the files inside the tarball are
different each time you create it, but this is not true if the tarball
is based on an upstream tag.

William

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Ben de Groot-2
On 23 February 2015 at 01:39, William Hubbs <[hidden email]> wrote:

> On Sat, Feb 21, 2015 at 09:18:08AM +0100, Michał Górny wrote:
>> neovim:
>>
>> > # Copyright 1999-2015 Gentoo Foundation
>> > # Distributed under the terms of the GNU General Public License v2
>> > # $Header: $
>> >
>> > EAPI=5
>> > inherit cmake-utils flag-o-matic
>> >
>> > DESCRIPTION="Vim's rebirth for the 21st century"
>> > HOMEPAGE="https://github.com/neovim/neovim"
>> > if [[ ${PV} == 9999 ]]; then
>> >     inherit git-r3
>> >     EGIT_REPO_URI="git://github.com/neovim/neovim.git"
>> >     KEYWORDS=""
>> > else
>> >     inherit vcs-snapshot
>> >     COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
>> >     SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} -> ${P}.tar.gz"
>>
>> I don't think relying on stability of generated tarballs is a good
>> idea. The same applies to almost all other ebuilds.
>
> If the tarball is based on an upstream tag, you should be fine, but this
> does not work for a commit hash like what is being used here.
>
> For more info on this, check out the man page for git archive. In
> particular, how it handles timestamps inside the tarball.
>
> In a nutshell, if you use git archive to create a tarball based on a
> commit hash, the time stamps of the files inside the tarball are
> different each time you create it, but this is not true if the tarball
> is based on an upstream tag.
>
> William

Thanks for the explanation! I'll roll tarballs then for our use until
upstream does tags or releases.

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Vadim A. Misbakh-Soloviov
In reply to this post by Ben de Groot-2
I'd also say:

neovim:

> CDEPEND="dev-lang/luajit
> <...>
> dev-lua/LuaBitOp

1) I'm not sure luajit:1 fits the dep
2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp

Unibilium:
1.1.2 made a day ago. Bump, please ;)

lua-MessagePack:
> RDEPEND=">=dev-lang/lua-5.1"
And what about LuaJIT? Huh?
Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can
be discussed. But main point is:

> RDEPEND="
>    !luajit? (
>        !lua53? (
>            || (
>                =dev-lang/lua-5.1*
>                =dev-lang/lua-5.2*
>            )
>        )
>        lua53? ( =dev-lang/lua-5.3* )
>    )
>    luajit?  ( dev-lang/luajit:2 )
>"
> <...>
>src_install() {
>    local lua=lua
>    use luajit && lua=luajit
>
>    insinto "$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})"
>    if use lua53; then
>        doins src5.3/MessagePack.lua
>    else
>        doins src/MessagePack.lua
>    fi
>}
(I wrote src_install that time when Makefile either was missing or buggy,
anyway, take a notice on conditions)




--
Best regards,
mva

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Ben de Groot-2
On 23 February 2015 at 14:17, Vadim A. Misbakh-Soloviov <[hidden email]> wrote:

> I'd also say:
>
> neovim:
>
>> CDEPEND="dev-lang/luajit
>> <...>
>>       dev-lua/LuaBitOp
>
> 1) I'm not sure luajit:1 fits the dep
> 2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp

Thanks! I don't know that much about lua, so this is very helpful.

> Unibilium:
> 1.1.2 made a day ago. Bump, please ;)

Already on it.

> lua-MessagePack:
>> RDEPEND=">=dev-lang/lua-5.1"
> And what about LuaJIT? Huh?

Yeah, but I just followed what I found upstream.

> Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can
> be discussed.

I don't mind either way. But again, I just followed upstream.

> But main point is:
>
>> RDEPEND="
>>    !luajit? (
>>        !lua53? (
>>            || (
>>                =dev-lang/lua-5.1*
>>                =dev-lang/lua-5.2*
>>            )
>>        )
>>        lua53? ( =dev-lang/lua-5.3* )
>>    )
>>    luajit?  ( dev-lang/luajit:2 )
>>"
>> <...>
>>src_install() {
>>    local lua=lua
>>    use luajit && lua=luajit
>>
>>    insinto "$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})"
>>    if use lua53; then
>>        doins src5.3/MessagePack.lua
>>    else
>>        doins src/MessagePack.lua
>>    fi
>>}

Thanks. But I think we can simplify that for now, since lua53 isn't
available (neither in the official tree or the lua overlay) and
>=lua-5.2 is hardmasked.

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] please review ebuilds for neovim and deps

Vadim A. Misbakh-Soloviov
>
> Thanks. But I think we can simplify that for now, since lua53 isn't
> available (neither in the official tree or the lua overlay) and
>
> >=lua-5.2 is hardmasked.

Anyway, I think, we need "my default patch for luajit support" here (which,
actually, I'd suggest to apply on all packages in the tree, that declares Lua
support. Should I start thread about it here?):

iuse+=luajit
deps~= luajit? (dev-lang/luajit:2) !luajit? ( dev-lang/lua )
or

src_configure/install {
local lua=lua
use luajit && lua=luajit

INST_PATH_LMOD=$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})"
# and/or INST_PATH_CMOD=$($(tc-getPKG_CONFIG) --variable INSTALL_CMOD ${lua})"
}

instead of "default" hard-dep on puc-rio lua... ;)

--
Best regards,
mva

signature.asc (836 bytes) Download Attachment