Re: [osv-dev] Re: Pip packages/using Nix
So is this getting published some place? ;-) Thanks, Roman. On Mon, Dec 14, 2020 at 9:00 AM Matthew Kenigsberg < matthewkenigsb...@gmail.com> wrote: > Thanks for putting so much effort into figuring that out! Really > appreciate it, and glad to get it working! > > On Wednesday, December 9, 2020 at 3:45:30 PM UTC-7 Matthew Kenigsberg > wrote: > >> That worked!!! Had to set -z relro -z lazy >> >> On Wednesday, December 9, 2020 at 12:30:55 PM UTC-7 jwkoz...@gmail.com >> wrote: >> >>> Hi, >>> >>> Thanks for uploading the files. It definitely has helped me figure out >>> the issue. >>> >>> In essence, all the .so files like libzfs.so are built with Full RELRO >>> (run 'readelf -a libzfso.so | grep BIND_NOW) on Nix OS it looks like. >>> Relatedly, some Linux distributions are setup to make gcc effectively use >>> '-z now -z relro' when linking the libraries. On many others like Ubuntu or >>> Fedora they are built with Partial RELRO - '-z relro' by default. >>> >>> As the libraries are loaded by OSv dynamic linker, all jump slot >>> relocations are resolved eagerly (even if they are not used by the code >>> later) if those libraries are marked as 'Full RELRO' (bind_now = true). For >>> non-'Full RELRO' cases, the jump slot relocations are resolved lazily >>> whenever they are accessed 1st time and are handled by 'void* >>> object::resolve_pltgot(unsigned index)` which writes resolved function >>> symbol address in GOT. >>> >>> The problem with Full-RELRO is that if we cannot find a symbol because >>> for example it is not implemented by OSv or is not visible at *this >>> point of linking* we simply ignore it hoping that it will never be used >>> or resolved later. If it is used later, the resolve_pltgot() is called, and >>> if the symbol is found (because the library containing the symbol has been >>> loaded since) we crash because we trying to write to the part of memory - >>> GOT - that has been since read-only protected. >>> >>> Why does this happen exactly? >>> >>> So here is the symbol *bsd_getmntany *not found at the address you were >>> getting original fault at (after adding extra debug statements): >>> ELF [tid:28, mod:3, /libzfs.so]: arch_relocate_jump_slot, >>> addr:0x10040ca0 >>> /libzfs.so: ignoring missing symbol *bsd_getmntany //Would have been >>> *0x10040ca8 >>> which match what page fault reports >>> ELF [tid:28, mod:3, /libzfs.so]: arch_relocate_jump_slot, >>> addr:0x10040cb0 >>> >>> Please note that both mkfs.so and zfs.so depend on libzfs.so. Per >>> command line, OSv loads and executes the apps sequentially. So the mkfs.so >>> is first and the dynamic linker will load libzfs.so and relocate and >>> eagerly resolve all symbols and fix the permissions on libzfs.so. One of >>> the symbols in libzfs.so is *bsd_getmntany* which is actually part of >>> zfs.so which is left unresolved (see missing warning above). >>> >>> After mkfs.so, OSv gets to zfs.so and it processes it and executes and >>> some of the code in zfs.so tries to invoke *bsd_getmntany *which gets >>> dynamically resolved and found by resolve_pltgot() BUT when it tries to >>> write to GOT it gets page fault. >>> >>> Having said all that I am sure what exactly the problem is: >>> A) Invalid or abnormal dependency between libzfs.so, mkfs.so and zfs.so >>> which effectively prevents those to function properly if build with Full >>> RELRO (would that work on Linux)? >>> B) True limitation of OSv linker which should handle correctly such >>> scenario. >>> >>> For now, the easiest solution (might be true if A is true) is to simply >>> force building those libraries with Partial RELRO like in this patch: >>> >>> diff --git a/Makefile b/Makefile >>> index d1597263..d200dde8 100644 >>> --- a/Makefile >>> +++ b/Makefile >>> @@ -345,7 +345,7 @@ $(out)/%.o: %.s >>> $(makedir) >>> $(call quiet, $(CXX) $(CXXFLAGS) $(ASFLAGS) -c -o $@ $<, AS $*.s) >>> >>> -%.so: EXTRA_FLAGS = -fPIC -shared >>> +%.so: EXTRA_FLAGS = -fPIC -shared -z relro >>> %.so: %.o >>> $(makedir) >>> $(q-build-so) >>> >>> Please let me know if it works, >>> Waldek >>> >>> PS. Also verify that running ' readelf -a libzfso.so | grep BIND_NOW' >>> does not show anything anymore. >>> >>> On Tuesday, December 8, 2020 at 5:08:18 PM UTC-5 Matthew Kenigsberg >>> wrote: >>> Not completely sure where libgcc_s.so.1 is coming from, but I uploaded what I have in /nix/store/vran8acwir59772hj4vscr7zribvp7l5-gcc-9.3.0-lib/lib/libgcc_s.so.1: https://drive.google.com/drive/folders/1rM6g-FrzwFpuHr2wX9-J21DzSjyQXGg2 Get a different error if I comment out core/elf.cc:1429: (gdb) bt #0 0x4039eef2 in processor::cli_hlt () at arch/x64/processor.hh:247 #1 arch::halt_no_interrupts () at arch/x64/arch.hh:48 #2 osv::halt () at arch/x64/power.cc:26 #3 0x4023c73f in abort (fmt=fmt@entry=0x40645aff "Aborted\n") at runtime.cc:132 #4 0x40202989 in abort () at
[osv-dev] [COMMIT osv master] travis: upgrade to newer docker base image - Ubuntu 20.10
From: Waldemar Kozaczuk Committer: Waldemar Kozaczuk Branch: master travis: upgrade to newer docker base image - Ubuntu 20.10 Signed-off-by: Waldemar Kozaczuk --- diff --git a/.travis.yml b/.travis.yml --- a/.travis.yml +++ b/.travis.yml @@ -7,7 +7,7 @@ branches: - master - ipv6 before_install: - - pushd docker && docker build -t osv/builder -f ./Dockerfile.builder --build-arg DIST="ubuntu-19.10" . && popd + - pushd docker && docker build -t osv/builder -f ./Dockerfile.builder --build-arg DIST="ubuntu-20.10" . && popd - docker run -it --privileged -d --name build osv/builder stages: - build_and_publish -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/7f38ea05b78bce80%40google.com.
[osv-dev] [COMMIT osv master] musl: fix __stdio_read.c to conform to new Musl
From: Nadav Har'El
Committer: Waldemar Kozaczuk
Branch: master
musl: fix __stdio_read.c to conform to new Musl
We have our own copy of __stdio_read.c because it was too complicated
to take Musl's as-is because of locking differences. However, there was
one recent change to that file we forgot to take:
In commit f92804188 in Musl's repository, Rich Felker (in Feb. 2018),
changed fread() to assume that f->read() returns 0 on error, instead
of -1. The same patch fixes __stdio_read() to return 0, and we need
to do this as well.
Without this patch, when the new Musl's fread() encounters an error (e.g.,
when you try to read from a directory), it will go into an infinite
loop - each iteration increases the remaining bytes (by 1) instead of
decreasing it by the number of read bytes as normal.
Signed-off-by: Nadav Har'El
Message-Id: <20201228135352.3246222-1-...@scylladb.com>
---
diff --git a/libc/stdio/__stdio_read.c b/libc/stdio/__stdio_read.c
--- a/libc/stdio/__stdio_read.c
+++ b/libc/stdio/__stdio_read.c
@@ -30,7 +30,7 @@ size_t __stdio_read(FILE *f, unsigned char *buf, size_t len)
if (cnt <= 0) {
f->flags |= F_EOF ^ ((F_ERR^F_EOF) & cnt);
f->rpos = f->rend = 0;
- return cnt;
+ return 0;
}
if (cnt <= len) return cnt;
cnt -= len;
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/6bb4f305b78bceb8%40google.com.
[osv-dev] [COMMIT osv master] scripts/setup.py: simplify Fedora's Lua requirement
From: Nadav Har'El Committer: Waldemar Kozaczuk Branch: master scripts/setup.py: simplify Fedora's Lua requirement Each of the Fedora releases just installs whatever Lua version is available in this release. It is pointless to specify the specific version to install, when this is what happens by default anyway. Signed-off-by: Nadav Har'El Message-Id: <20201228105035.3239757-1-...@scylladb.com> --- diff --git a/scripts/setup.py b/scripts/setup.py --- a/scripts/setup.py +++ b/scripts/setup.py @@ -63,55 +63,57 @@ class Fedora(object): 'yaml-cpp-devel', 'pax-utils', 'java-1.8.0-openjdk', +'lua', +'lua-devel', ] ec2_packages = standard_ec2_packages test_packages = ['openssl-devel'] ec2_post_install = standard_ec2_post_install class Fedora_27(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '27' class Fedora_28(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '28' class Fedora_29(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '29' class Fedora_30(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '30' class Fedora_31(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '31' class Fedora_32(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '32' class Fedora_33(object): -packages = ['lua-5.4.*', 'lua-devel-5.4.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/579fdd05b78bced2%40google.com.
[osv-dev] [COMMIT osv master] aarch64: synchronize data and instruction caches after loading code into memory
From: Waldemar Kozaczuk
Committer: Waldemar Kozaczuk
Branch: master
aarch64: synchronize data and instruction caches after loading code into memory
This is quite small and simple patch but it has taken me almost 2 months
researching and understanding the problem and finding the right solution. It
has involved reading ARMv8 programmer guide, posting questions to ARM forums
as well as trying to debug the problem mostly in trial-and-error fashion as
somewhat
documented by the issue #1100. The special credit goes to Claudio
Fontana who helped me tremendously by explaining and suggesting
many valuable ideas.
As the issue #1100 explains, OSv would occasionally or quite repeatedly
depending on the application, crash due to an unexpected Unknown Reason
class synchronous exception (EC=0). This would never happen in emulated
mode (QEMU with TCG) but quite freqently on real ARM hardware like RPI 4
on QEMU with KVM or Firecracker. Per ARM documentation -
https://developer.arm.com/docs/ddi0595/h/aarch64-system-registers/esr_el1#ISS_exceptionswithanunknownreason
- there are many potential causes of EC=0 exception including "attempted
execution
of an instruction bit pattern that has no allocated instruction" which
means trying to execute garbage.
All of those potential causes which I quite meticulously researched,
examined and discussed some with Claudio, did not seem to apply or did
not make much sense in OSv context. Until one of them did when I stumbled
across this article -
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/caches-and-self-modifying-code
- about "self-modifying code". Initially this article seemed to apply to
JIT-type of scenarios
but then after eventually seeing this small font annotation:
"A more common (though less obvious) example is that of an operating
system kernel: from the point of view of the processor, some code in the
system is modifying some other code in the system every time a process
is swapped in or out." it kind of started making me think that OSv
dynamic linker is somewhat close.
Then I eventually found this paragraph in ARMv8 programmer's guide
in chapter 11.5 "Cache maintenance":
"It is sometimes necessary for software to clean or invalidate a cache.
This might be required when the contents of external memory have been
changed and it is necessary to remove stale data from the cache. It can
also be required after MMU-related activity such as changing access
permissions, cache policies, or virtual to Physical Address mappings, or
when I and D-caches must be synchronized for dynamically generated code
such as JIT-compilers and dynamic library loaders."
In essence aarch64 architecture (Modified Harvard) defines separate
instruction and data caches - I-cache and D-cache. Therefore it is sometimes
necessary to synchronize both caches with each other by cleaning the D-cache
and invalidating the I-cache cache after loading code into memory.
Which is exactly what the article about self modifying code explains.
How does it apply to OSv? Well, OSv dynamic linker being part of kernel (code
A) loads
into memory application code (B), which by itself does not mean OSv
modifies its own kernel code however it dynamically loads another code
and executes it in the same memory space.
Making this long story short, this patch modifies critical part
of OSv memory management code - populate_vma() - which gets called any time
vma portion (page) is filled due to page fault or eagerly. It changes
the populate_vma() by making it synchronize the data and instruction caches
with each other if the vma is executable per its permission -
in essence any time any code is loaded into memory.
To achieve it delegates to an obscure built-in - __clear_cache().
This logic is actually no-op in x86-64 port, as this architecture has strong
coherency between instruction and data caches and there is no need to do
anything
special in this case.
Fixes #1100
Signed-off-by: Waldemar Kozaczuk
---
diff --git a/arch/aarch64/mmu.cc b/arch/aarch64/mmu.cc
--- a/arch/aarch64/mmu.cc
+++ b/arch/aarch64/mmu.cc
@@ -97,4 +97,38 @@ bool is_page_fault_write_exclusive(unsigned int esr) {
bool fast_sigsegv_check(uintptr_t addr, exception_frame* ef) {
return false;
}
+
+void synchronize_cpu_caches(void *v, size_t size) {
+// The aarch64 qualifies as Modified Harvard architecture and defines
separate
+// cpu instruction and data caches - I-cache and D-cache. Therefore it is
necessary
+// to synchronize both caches by cleaning data cache and invalidating
instruction
+// cache after loading code into memory before letting it be executed.
+// For more details of why and when it is necessary please read this
excellent article -
+//
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/caches-and-self-modifying-code
+// or this paper - https://hal.inria.fr/hal-02509910/document.
+//
+// So when OSv dynamic linker,
Re: [osv-dev] [PATCH] musl: fix __stdio_read.c to conform to new Musl
On Mon, Dec 28, 2020 at 5:24 PM Waldek Kozaczuk
wrote:
> How did you discover this bug?
>
I am trying to run Lua 5.4, and because of misconfiguration, I caused it to
read a file with an empty name (!)
and this resulted in read errors, and fread() just went into an endless
loop and I had to debug why
Then I found the incorrect logic in fread(), and "git blame" told me the
logic is correct, if you change __stdio_read() accordingly - and it turns
out that's what they did in Musl.
I was too lazy to write a unit test that reproduces the bug. But I should!
It should be very easy (a simple fread() from a directory should result in
an endless loop) I will do it later.
> Sent from my iPhone
>
> > On Dec 28, 2020, at 08:54, Nadav Har'El wrote:
> >
> > We have our own copy of __stdio_read.c because it was too complicated
> > to take Musl's as-is because of locking differences. However, there was
> > one recent change to that file we forgot to take:
> >
> > In commit f92804188 in Musl's repository, Rich Felker (in Feb. 2018),
> > changed fread() to assume that f->read() returns 0 on error, instead
> > of -1. The same patch fixes __stdio_read() to return 0, and we need
> > to do this as well.
> >
> > Without this patch, when the new Musl's fread() encounters an error
> (e.g.,
> > when you try to read from a directory), it will go into an infinite
> > loop - each iteration increases the remaining bytes (by 1) instead of
> > decreasing it by the number of read bytes as normal.
> >
> > Signed-off-by: Nadav Har'El
> > ---
> > libc/stdio/__stdio_read.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libc/stdio/__stdio_read.c b/libc/stdio/__stdio_read.c
> > index 8fec9c35..30d7aac5 100644
> > --- a/libc/stdio/__stdio_read.c
> > +++ b/libc/stdio/__stdio_read.c
> > @@ -30,7 +30,7 @@ size_t __stdio_read(FILE *f, unsigned char *buf,
> size_t len)
> >if (cnt <= 0) {
> >f->flags |= F_EOF ^ ((F_ERR^F_EOF) & cnt);
> >f->rpos = f->rend = 0;
> > -return cnt;
> > +return 0;
> >}
> >if (cnt <= len) return cnt;
> >cnt -= len;
> > --
> > 2.29.2
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "OSv Development" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to osv-dev+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/20201228135352.3246222-1-nyh%40scylladb.com
> .
>
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/CANEVyjsqcJ%3Dw9BC3bcCt3ho7-yxd_9YVOOsoacD8DrEDhzYfHQ%40mail.gmail.com.
Re: [osv-dev] [PATCH] musl: fix __stdio_read.c to conform to new Musl
How did you discover this bug?
Sent from my iPhone
> On Dec 28, 2020, at 08:54, Nadav Har'El wrote:
>
> We have our own copy of __stdio_read.c because it was too complicated
> to take Musl's as-is because of locking differences. However, there was
> one recent change to that file we forgot to take:
>
> In commit f92804188 in Musl's repository, Rich Felker (in Feb. 2018),
> changed fread() to assume that f->read() returns 0 on error, instead
> of -1. The same patch fixes __stdio_read() to return 0, and we need
> to do this as well.
>
> Without this patch, when the new Musl's fread() encounters an error (e.g.,
> when you try to read from a directory), it will go into an infinite
> loop - each iteration increases the remaining bytes (by 1) instead of
> decreasing it by the number of read bytes as normal.
>
> Signed-off-by: Nadav Har'El
> ---
> libc/stdio/__stdio_read.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libc/stdio/__stdio_read.c b/libc/stdio/__stdio_read.c
> index 8fec9c35..30d7aac5 100644
> --- a/libc/stdio/__stdio_read.c
> +++ b/libc/stdio/__stdio_read.c
> @@ -30,7 +30,7 @@ size_t __stdio_read(FILE *f, unsigned char *buf, size_t len)
>if (cnt <= 0) {
>f->flags |= F_EOF ^ ((F_ERR^F_EOF) & cnt);
>f->rpos = f->rend = 0;
> -return cnt;
> +return 0;
>}
>if (cnt <= len) return cnt;
>cnt -= len;
> --
> 2.29.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/20201228135352.3246222-1-nyh%40scylladb.com.
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/080C310B-B33A-4F2C-AE27-C18A21B288E5%40gmail.com.
[osv-dev] [PATCH] musl: fix __stdio_read.c to conform to new Musl
We have our own copy of __stdio_read.c because it was too complicated
to take Musl's as-is because of locking differences. However, there was
one recent change to that file we forgot to take:
In commit f92804188 in Musl's repository, Rich Felker (in Feb. 2018),
changed fread() to assume that f->read() returns 0 on error, instead
of -1. The same patch fixes __stdio_read() to return 0, and we need
to do this as well.
Without this patch, when the new Musl's fread() encounters an error (e.g.,
when you try to read from a directory), it will go into an infinite
loop - each iteration increases the remaining bytes (by 1) instead of
decreasing it by the number of read bytes as normal.
Signed-off-by: Nadav Har'El
---
libc/stdio/__stdio_read.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libc/stdio/__stdio_read.c b/libc/stdio/__stdio_read.c
index 8fec9c35..30d7aac5 100644
--- a/libc/stdio/__stdio_read.c
+++ b/libc/stdio/__stdio_read.c
@@ -30,7 +30,7 @@ size_t __stdio_read(FILE *f, unsigned char *buf, size_t len)
if (cnt <= 0) {
f->flags |= F_EOF ^ ((F_ERR^F_EOF) & cnt);
f->rpos = f->rend = 0;
- return cnt;
+ return 0;
}
if (cnt <= len) return cnt;
cnt -= len;
--
2.29.2
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/20201228135352.3246222-1-nyh%40scylladb.com.
Re: [osv-dev] Fedora 33 issues
On Sun, Dec 27, 2020 at 10:28 PM Waldek Kozaczuk wrote: > Also I noticed some cli command produce some lua runtime warnings about > nil (ls -l) with 5.4. So we would also need to change our lua code to make > it perfectly work with newer versions. > > So if we can stick to 5.3 it would be best. > I seems that sticking to 5.3 is mess. Strangely, Fedora 33 includes shared libraries for both Lua 5.3 and 5.4, but the /usr/bin/lua is only 5.4, and the "luarocks" sript is hard-coded to use it. So it would be best if we could just use whatever Lua is available on the host. I'll see what it takes to make 5.4 (from Fedora 33) work. > On Sun, Dec 27, 2020 at 15:08 Waldek Kozaczuk > wrote: > >> In theory we do need to insist on 5.3 but then the lua module makefile >> has dependencies on concrete lua libraries which may be >> incompatible/unavailable for that lua version. So that makefile would >> somehow need to take that into account. >> >> Sent from my iPhone >> >> On Dec 27, 2020, at 12:28, Nadav Har'El wrote: >> >> >> >> On Sun, Dec 27, 2020 at 7:02 PM Nadav Har'El wrote: >> >>> On Tue, Nov 24, 2020 at 6:01 PM Waldek Kozaczuk >>> wrote: >>> Even though I applied a patch that nominally adds support of Fedora 33 in terms of setup, there are some issue I have found: ... 2. The lua module no longer build as Fedora 33 comes with the version 5.4 and we rely on 5.3. We should somehow modify the modules/lua/Makefile to support both (any?) versions of Lua on the host. >>> >>> Yes, if our plan is to copy whatever Lua version exists on the host, why >>> should we be so specific as insisting on version 5.3. >>> >> >> It turns out that Fedora 33 actually does have the Lua library 5.3, not >> just 5.4, and the problem may be the specific Luarocks executable we >> download. I'll try to figure out what's the problem. I'm not a Lua expert. >> Not even a Lua fan ;-) >> >> >>> If 5.5 comes out, why not use that? >>> (of course, 5.5 may not work because they changed something, etc., but >>> at least it won't trivially break when we are missing the entire package). >>> >>> I'll try to produce a patch for this. >>> >>> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CANEVyju3By7K%2BbHtx4uJ6msqy8LBsiA%3DBObCmHhKwpmHein67A%40mail.gmail.com.
[osv-dev] [PATCH] scripts/setup.py: simplify Fedora's Lua requirement
Each of the Fedora releases just installs whatever Lua version is available in this release. It is pointless to specify the specific version to install, when this is what happens by default anyway. Signed-off-by: Nadav Har'El --- scripts/setup.py | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/scripts/setup.py b/scripts/setup.py index a30ee345..3cf45eac 100755 --- a/scripts/setup.py +++ b/scripts/setup.py @@ -63,55 +63,57 @@ class Fedora(object): 'yaml-cpp-devel', 'pax-utils', 'java-1.8.0-openjdk', +'lua', +'lua-devel', ] ec2_packages = standard_ec2_packages test_packages = ['openssl-devel'] ec2_post_install = standard_ec2_post_install class Fedora_27(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '27' class Fedora_28(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '28' class Fedora_29(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '29' class Fedora_30(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '30' class Fedora_31(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '31' class Fedora_32(object): -packages = ['lua-5.3.*', 'lua-devel-5.3.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None version = '32' class Fedora_33(object): -packages = ['lua-5.4.*', 'lua-devel-5.4.*'] +packages = [] ec2_packages = [] test_packages = [] ec2_post_install = None -- 2.29.2 -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/20201228105035.3239757-1-nyh%40scylladb.com.
