On 02/23/2016 01:27 PM, James McCoy wrote:
>> Yes, but that does not mean we should accept that in Debian. Debian
>> specifically aims to provide a universal distribution which runs
>> on a large number of different targets and everyone should therefore
>> help to keep their own packages available
On Tue, Feb 23, 2016 at 10:55:04AM +0100, John Paul Adrian Glaubitz wrote:
> On 02/23/2016 02:43 AM, James McCoy wrote:
> >> I still don't see what warrants the requirement of LuaJIT in a text
> >> editor which could not replaced by the regular Lua interpretor.
> >
> > As I mentioned earlier, LuaC
On 02/23/2016 02:43 AM, James McCoy wrote:
>> The moment they start embedding LuaJIT into neovim, the package needs
>> to be patched or it will be removed out of Debian.
>
> That's a bit of an overreaction. What I meant was what's typically
> meant when talking of embedding a language[0][1][2] (e
On Mon, Feb 22, 2016 at 02:08:23PM +0100, John Paul Adrian Glaubitz wrote:
> On 02/22/2016 01:05 PM, James McCoy wrote:
> > It's currently possible to build without LuaJIT, as long as you don't
> > want to run tests. However there are plans to embed LuaJIT into neovim.
>
> The moment they start em
On 02/22/2016 01:05 PM, James McCoy wrote:
> It's currently possible to build without LuaJIT, as long as you don't
> want to run tests. However there are plans to embed LuaJIT into neovim.
The moment they start embedding LuaJIT into neovim, the package needs
to be patched or it will be removed out
On Feb 22, 2016 6:58 AM, "John Paul Adrian Glaubitz" <
glaub...@physik.fu-berlin.de> wrote:
>
> On 02/22/2016 12:55 PM, James McCoy wrote:
> >> No, I'm sorry. This isn't the correct way to handle this. You either
> >> update the Architecture list in debian/control or you make neovim
> >> use LuaC w
On 02/22/2016 12:55 PM, James McCoy wrote:
>> No, I'm sorry. This isn't the correct way to handle this. You either
>> update the Architecture list in debian/control or you make neovim
>> use LuaC when it cannot use LuaJIT.
>
> LuaC didn't provide FFI, as I understand it, which is why LuaJIT is
> b
On Feb 22, 2016 2:18 AM, "John Paul Adrian Glaubitz" <
glaub...@physik.fu-berlin.de> wrote:
>
> Control: reopen -1
>
> On 02/22/2016 05:23 AM, James McCoy wrote:
> > After talking with them, I'm going to close this. Neovim is likely
> > to become even more reliant on luajit in the future, so
> > c
Control: reopen -1
On 02/22/2016 05:23 AM, James McCoy wrote:
> After talking with them, I'm going to close this. Neovim is likely
> to become even more reliant on luajit in the future, so
> conditionally depending on it isn't really an option.
No, I'm sorry. This isn't the correct way to handle
On Tue, Jan 26, 2016 at 10:03:31AM +0100, John Paul Adrian Glaubitz wrote:
> neovim is currently BD-Uninstallable on a number of architectures which
> are not supported by luajit [1]. I would therefore like to ask to limit
> the list of architectures for which neovim build-depends on libluajit-5.1-
Package: neovim
Version: 0.1.1-3
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hello!
neovim is currently BD-Uninstallable on a number of architectures which
are not supported by luajit [1]. I would therefore like to ask to limit
the list of architectures for which neo
11 matches
Mail list logo
